adelevie

I can't give a comprehensive answer as to how we hire, but I can offer my personal experience: I was able to finish my last year of part-time law school when I started at 18F. I was working full time, and everyone was very respectful about having a life outside of work.

In the shorter term, do check out https://micropurchase.18f.gov. It's where we post very short term contract opportunities ($3,500 or less, and tasks typically take up to a week). I also happen to be a dev on this project, so feel free to reach out here or at [email protected] if you have any questions.

18F is hardly the only group within government using OSS to build websites. Also hardly the first (CFPB was at it before 18F existed), I'm sure there are more way before CFPB.

According to https://www.govcode.org/repos, there are about 1,300 U.S. government repos on GitHub that do not belong to 18F.

If you're generally interested in how we do ATOs, https://pages.18f.gov/before-you-ship/ato/ is a nice internal guide for our devs.

(I work at 18F)

> The person is assuming ill-intent on behalf of the speaker.

This is where these kinds of issues typically go off the rails. With male-gendered language as the default, I doubt very many people intend to do anything wrong. It's how I learned to speak and I'm sure it's how many others did, too.

A silly nudge from a Slack bot, is just that--not an accusation or a judgment of character.

I was thinking about this a bit more last night, and I thought of another reason why the bot is great: it doesn't discriminate. It doesn't matter if you are in leadership at 18F, a guest user in our Slack, an employee who started two weeks ago, male, female, or something else. The bot doesn't care.

There's a bit of politics to how people get "called out"--e.g. who wants to pull the boss aside and correct their behavior? The end result is likely to be that certain employees get corrected and other employees don't. A bot avoids all of this.

Employees who are happy and feel included are going to produce better work (and a better return on the invested tax dollar) than those who aren't. I'd also expect second-order benefits such as helping us recruit from a wider, more diverse pool of applicants.

Of course there are boundaries to the happiness-increases-productivity dynamic, but quickly coding up a Slack bot seems well within the safe range.

I work at 18F, here's my hot take:

It's been pretty well established that needlessly (male) gendered language makes people feel excluded. Actually, that's too nice. That kind of language excludes people. Period.

It communicates that the speaker does not contemplate a non-male audience. I do not know about the communities that you moderate, but constantly assuming a male audience at a place like 18F is wrong factually and is disrespectful.

I've triggered the slackbot by using "guys" many times and I've never felt that this was aggressive in any way. It's usually a chuckle-worthy experience for all involved. And that's why I love the bot. I do understand concerns over "policing" language. No one wants to feel pestered into writing/talking in a way that feels unnatural to them. However, instincts should not be above criticism. And a silly bot[0] is a great way to gently, politely, and humorously help people unlearn behavior that excludes.

[0] We have other silly bots, too. The one we probably love to hate the most is angrytock (https://github.com/18f/angrytock), which will remind us to submit our time cards (using our open source time tracker, Tock. https://github.com/18f/tock).

https://github.com/18f?utf8=%E2%9C%93&query=fec :)

I should have read the [] manual :)

This is really neat! For work, I've found myself from time to time exploring the tech around PDFs. I find this tech strangely fascinating. It's like a shim on top of something old and ugly that enables integration with much more modern systems.

Some quick feedback (and a shameless plug):

The CLI interface should output JSON. It would be nice to combin with a CLI JSON parser such as jq[0].

Shameless plug: I've been working on a PDF CLI aimed at making it easier to programmatically fill out PDF forms: https://github.com/adelevie/pdfq. It provides an interface and some wrappers on top of the main pdf form-filling tool, pdftk. For example, you can get json out of a pdf form like this:

    pdftk hello.pdf dump_data_fields | pdfq

Or you can generate FDF from a json file:

    cat hello.json | pdfq json_to_fdf

You can also fill a pdf without touching an fdf code:

    pdfq set foo bar input.pdf output.pdf

[0] https://stedolan.github.io/jq/

I'd love to see an open source project around scanning the GitHub API and subscribing to alerts for your org's repos.

I like https://fugacio.us/ a lot.

A colleague at 18F built https://www.govcode.org/. It's a handy directory of U.S. federal government open source projects.

I'd love to see blog posts or any write-ups about your experiences founding an ISP.

No office there, but we have at least one remote staffer in Austin.

> Are the dissenting opinions available?

Yes. Keep scrolling :)

I put together some quick and dirty scripts for searching the text of the Order: https://github.com/adelevie/open-internet-order.

I'm on a team working on immigration at 18F. Not sure why you assume it's miserable. Anyways, we're using a modern Rails/Postgres/Elasticsearch stack and the work is incredibly rewarding and motivating. Here's a nice description:

> 18F is working with a number of different federal departments. One of the biggest projects it has taken on is designing the website for U.S. Citizenship and Immigration Services. That's the agency that processes applications from people hoping to become citizens and those covered under the president's executive actions who hope to obtain work permits. Godbout says the concept for the USCIS website is to make a virtual welcoming statement.

> He thinks of it as an "online Statue of Liberty. This idea of how do we present ourselves to people coming to America. Our digital process should be that beautiful, too."

source: http://www.npr.org/blogs/alltechconsidered/2015/01/28/382178...

That's a great question. At 18F, we <3 APIs[0][1][2][3][4][5]. Not only are we big believers ourselves, but we strive to help other agencies improve their API practices.

[0] https://github.com/18F/api-standards

[1] https://github.com/18F/jekyll_pages_api

[2] https://github.com/18F/API-All-the-X and http://18f.github.io/API-All-the-X/

[3] https://github.com/18F/api.data.gov

[4] https://github.com/18F/fbopen

[5] https://github.com/18f/?query=api etc, etc

Is this comparable to IronWorker?

At 18F (a digital services consultancy within the US federal government), we've drafted API Standards[1]. They're a set of recommendations, rebuttable presumptions, and bright line rules that we expect our APIs to adhere to. For an organization that may offer several APIs, having a set of standards will help ensure, among other things, baseline quality and consistency.

[1] https://github.com/18f/api-standards

This is a great example of how privacy is not optional, even in "opt-in" systems such as Instagram and FB. That Instagram does not require you to have a Facebook profile, and Facebook does not require you to list gender means very little in terms of your own privacy.

Merely choosing to withhold information about yourself does not insulate you from a breach of privacy. That others do disclose such information allows 3rd parties to make really good guesses and inferences about you.

There's a strange morality here: at what point is it unethical to voluntarily disclose data about oneself, if it could be used in a way to harm someone else's privacy? Short of drawing a moral boundary (it could very well be impossible), we might do well to at least acknowledge the cost to these methods, alongside their benefits.

This reminds me of the wonderfully cool Web 2.0-era startup Dapper.

I sent a pull request with a chapter on diffs[1]. They're important in their own right, but also as a good precursor to the inevitable git/github/version control chapter[2].

[1] (https://github.com/vzvenyach/codingforlawyers/pull/10) [2] https://github.com/vzvenyach/codingforlawyers/issues/5

Check out https://permafrast.herokuapp.com. OP built this as well, and it makes it really easy to read cases without signing into Lexis, Westlaw, or, well ... anything.

Just one of many examples of how lawyers can use tech to make their day jobs easier.

I'm not the author (but I know him and he doesn't have an HN account--I've also contributed a chapter currently awaiting as a PR). PRs are certainly welcome.

Steve Marx created webscript.io. He's now a Developer Advocate at Dropbox[1].

[1] https://twitter.com/smarx

Thanks for the detailed reply! I turned this into an issue on our GitHub repo here: https://github.com/18F/api-standards/issues/45.

Interesting re header data. Could you elaborate as to what kind of data belongs in headers, and explain why putting this data in headers should be a bright line requirement or a "sane default"?

If you'd like to elaborate in a way that would be highly visible to 18F, feel free to weigh in on the issues page[1].

I will point out that JSON is recommended as a default, and if there is a compelling reason not to use it in a specific case, that should be fine[2].

[1] https://github.com/18f/api-standards/issues or https://github.com/18F/api-standards/issues/8

[2] https://github.com/18F/api-standards#just-use-json

It's really great to see this on HN. Major kudos should go to Eric Mill, Gray Brooks, and everyone else who contributed[1] to these standards (as well as the White House, whose API standards 18F forked[2]). There is a blog post[3] that further explains 18F's goals for these standards, as well as a bit on how 18F evaluates what becomes a standard and what does not.

These were discussed out in the open, and meaningful feedback, suggestions, or pull requests are certainly welcome.

[1] https://github.com/18F/api-standards/blame/master/README.md

[2] https://github.com/WhiteHouse/api-standards

[3] http://18fblog.tumblr.com/post/91868213233/hot-off-the-press...