This is the first post in my All Things Open 2015 Series.

What makes a health community? What are examples of healthy communities? What features can we lift from successful communities for our own teams and projects?

Goals and principles

The defining feature of open source projects and communities is directly in the name: “openness”.

There was a great keynote on the first day by Red Hat’s CEO, Jim Whitehurst. He defined an “open organization” to be

An organization that engages participative communities both inside and out

Organizations must welcome all kinds of input from all kinds of people to attract and retain talent.

Nuts and bolts

There were some great tips that people felt contributed to the above goals. Two of the key talks in this area were Brandon Keeper’s Open Source Principles for Better Engineering Teams and Kaitlin Devine’s Power to the People: Transforming Government with Open Source. They both had great things to say about how their respective organizations worked (GitHub & 18F) in a distributed fashion and interacted with the community. The core points were to:

• Communicate via methods that are permanent, asynchronous mediums
• Have a strong code of conduct
• Learn by lurking / teach by doing
• Automate grunt work

One fact that Brandon highlighted was that, historically, open source projects never had the luxury of face to face meetings. Instead, they use issue tracking systems, mailing lists, and version control systems to communicate. The permanent record provided by these tools helps newcomers learn the ropes. The asynchronous nature of these tools (You can e-mail a mailing list, and continue working until someone responds) means that people can respond at their leisure and you can keep working until you get a response.

Brandon noted that at GitHub, they respond to questions with a URL (to documentation, a pull request, or a blog post). He stated that informal knowledge stops a conversation:

Alice: Why don’t we do it this way?
Bob: We tried that a few years ago and it didn’t work

A durable, search-able knowledgebase lets the conversation continue:

Alice: Why don’t we do it this way?
Bob: We tried that a few years ago and it didn’t work. See http://link-to-project
Alice (some time later): I see — since then, there have been these new advances. It might be worth trying some of them to see if this would work now.

Kaitlin talked about the importance of having a strong code of conduct. A code of conduct protects community members by making it clear what kind of conduct is appropriate and what the procedure is when someone violates it. An easy way to make your code of conduct prominent on a project-by-project basis is to link to it prominently from both the README.md and CONTRIBUTING.md documents.

The conference itself was a good example of a community with a strong code of conduct. Each communication from the organizing committee mentions the code of conduct.

The way we start working with communities (open source or otherwise) is important. He stated that new OSS project members learn by doing and veteran members teach by doing.

In the course of their daily work veteran community members work primarily on durable mediums. By responding to questions and requests with links (references to the durable record), they teach new community members to work the same way. Similarly, by responding to code of conduct violations in a public fashion, new members know what to expect and how to handle violations. This both promotes a safe space and reinforces community norms.

The final thought that resonated with me was the automation of grunt work. Github employees go out of their way to automate grunt work so that people can keep working on the hard parts of their jobs. Some of the things that they automate include:

1. Automating coding standard checking and other basic warnings: this way, code reviews end up being about the substance of the code and not important, but nitpicky details.
2. Writing style: the GitHub blog uses automated checks to ensure quality. In particular, they have a Jenkins job that flags common writing flaws by running candidate posts through the write-good. This promotes a consistent style across the blog, and once again eliminates simple errors and lets human reviewers focus on the substance of the post.
3. Blog post calendar: They considered appointing someone to organize when specific entries would get posted to the blog to ensure that there was a regular flow of posts. Instead, they added another Jenkins job that throws an error if a day has too many entries. If a day is too full, the job suggests that you schedule your post for a different day.

What I love about these suggestions is that they take the common machinery required to work day-to-day and focuses it to providing thoughtful feedback. Computers handle the minutiae that they are best at.

There was a lot of good “how to manage a community” sprinkled throughout ATO this year. I plan on taking these ideas and trying to drive them in my own teams and projects.

This is the third year that I’ve had the pleasure of attending All Things Open in Raleigh, NC.

The conference has gotten bigger every year. This year there were 1,700 attendees across thirteen tracks. The tracks cover a variety of technical topics ranging from JavaScript/web development to big data, to community management.

I haven’t previously blogged about the talks I go to. This year (I tell myself) will be different.

This year is big enough that I’m going to highlight several different themes and projects that really caught my attention over the two days. I’ll write a post on each of the following topics:

1. Community: community is a big part of All Things Open, and many of the talks are either specifically about open source communities, or peripherally mention them as a key to technical success. I think there were a lot of good takeaways on how to engineer communities to be inclusive, productive, and self-sustaining.
2. Development & Deployment Environments: While I’d previously been aware of tools like Docker and Vagrant, hearing experts talk about them and give live demonstrations really cements what these tools are for and how they can be used to simplify my life as a developer, researcher, and systems administrator.
3. Big Data: I went to several of the big data talks — this year there were two great talks on using Apache Nifi and Apache Spark to ingest and explore data.
4. Graph Databases: Graph databases (like Neo4J) are an interesting take on databases. Again, it was instructive to see an expert talk about graph databases and give a live demonstration.
5. Rust: The Rust programming language is an interesting new programming language that’s seen a considerable amount of development over the previous year.
6. SrcML.NET: There was no talk on SrcML.NET this year — however, as its primary maintainer, I hope to apply many of the social and technical ideas I learned this year to the project.

As I write each post, I’ll update this post with a link.