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.