Wednesday, June 8, 2016

Open Source at Docker, Part 2: The Processes [feedly]



----
Open Source at Docker, Part 2: The Processes
// Docker Blog

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.

This post is the second of a 3-part series on how we deal with those challenges on the Docker Engine project. Part 1 was about the people, part 2 covers the processes.
 

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.

Our processes are tailored for a great #opensource contributor experience first – @icecrime
Click To Tweet

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).

 

status_opensource

 

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 2-code-review to 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.

 

status_failing_ci
status_needs_attn

 

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.

Best way to became an #opensource maintainer is to start helping like one – @icecrime
Click To Tweet

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!
 

What's next

There would be a lot more to say about our issue triage, our release process, or our maintainer meetings. Feel free to come ask questions on IRC if you are curious, or read through the documentation!

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.

Read more about #OpenSource at #Docker, Part 2: The Processes by @icecrime
Click To Tweet

 

Learn More about Docker


----

Shared via my feedly newsfeed


Sent from my iPhone
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)