The Docker open source project is among the most successful in recent history by every possible metric: number of contributors, GitHub stars, commit frequency, … Managing an open source project at that scale and preserving a healthy community doesn’t come without challenges.
Optimizing the right thing
The numbers we have shown in this series’ previous blog post demonstrates the scale at which we are operating, and the huge amount of contributions that Docker receives from people who are neither maintainers nor employees. I believe that a reason for that is that our processes are tailored for a great contributor experience first, and to optimize maintainer time (a very scarce resource!) second.
Contributors and maintainers have a very different perspective: the former have put significant amount of effort in a pull request and want feedback in a timely manner, while the latter are battling to stay on top of an overwhelming flow of contributions (there is the typical “pet versus cattle” analogy to be made here). For both these actors, visibility is key: understanding how far a contribution is in the process, what is the next step, and who is responsible for it.
We improve visibility thanks to an extensive use of GitHub labels. In particular, we model the pull request reviewing workflow as an iterative process where every step is associated with a numbered label. The order of these steps is meant to avoid frustration for the contributor: for example, we don’t want to have someone fix typos in the documentation unless we are reasonably confident the changeset will get merged (code and design approved).
Each pull request can only be in one of those states at a given point in time, and how we transition from one step to the next is pretty straightforward: for example, going from
3-docs-review requires two maintainers to comment with “LGTM” (Looks Good To Me). But here again, it’s the underlying trust and mutual respect that makes the project work smoothly while preserving a high level of quality. Participants’ opinions are not taken lightly, and an established member of the community expressing legitimate concerns against a particular pull request will usually call for more discussion until consensus can hopefully be reached.
In addition to the reviewing workflow, we use a few special labels to keep track of pull requests that aren’t making good progress and need maintainers’ attention, or pull requests that are currently not passing tests.
This is all about giving to contributors and maintainers alike an understanding of progress at first sight. As any other process in the project, its description is stored in the repository and managed as code: if you want to improve the pull request reviewing process, you’ll have to send a pull request for it! And of course, feel free to copy our rules for your project (you can even easily replicate our labels).
Becoming a maintainer
I’ve already mentioned maintainers a lot in this blog series, but how can somebody become one? Well guess what: the rules are documented in a repository and managed as code.
We want to make it possible for anyone to become a maintainer, regardless of experience and amount of time one can dedicate to the project. Hence, what we’re looking at is regularity: it’s about being an active member of the community for an extensive period of time (over 3 months). The maintainers will notice that, and eventually they will start a vote on the mailing list to grant commit rights.
But being an active member of the community is not only about submitting code. It’s also about helping to review other people’s code, coaching them with their pull requests, answering questions, reproducing issues, … Really, the best way to become a maintainer is to start helping like one.
Finally, a fun fact is that even Docker employees must earn their maintainer rights. How so? Well, by becoming an active member of the community for an extensive period of time and get voted by the other maintainers!
Maintainer activity, pull requests, issues, … All those things can be measured, some tasks can be automated, and this is exactly what the next and final post of the series will cover.
Learn More about Docker
- New to Docker? Try our 10 min online tutorial
- Share images, automate builds, and more with a free Docker Hub account
- Read the Docker 1.11 Release Notes
- Subscribe to Docker Weekly
- Sign up for upcoming Docker Online Meetups
- Attend upcoming Docker Meetups
- Register for DockerCon 2016
- Watch DockerCon EU 2015 videos
- Start contributing to Docker