Ever since I’ve been involved with OpenStack people have been complaining that upstream is hard. The number one complaint is that it takes forever to get your patches merged. I thought I’d take a look at some data and attempt to visualize it. I wrote some code that accepts an OpenStack project and a list of contributors and spits out a bunch of graphs. For example:

• How long does it take to merge patches in a given project over time? Looking back, did governance changes affect anything?
• Is there a correlation between the size of a patch and the length of time it takes to merge it? (Spoiler: The answer is… Kind of)
• Looking at an author: Does the time to merge patches trend down over time?
• Looking at the average length of time it takes to merge patches per author, how does it look like when we graph it as a function of the author’s number of patches? Reviews? Emails? Bug reports? Blueprints implemented?

The data suggestes answers for many of those questions and more.

Here’s the code for you to play with:

https://github.com/assafmuller/gerrit_time_to_merge

And some conclusions in the slides embedded below:

https://docs.google.com/presentation/d/17l720kXrAHJC9_gU81nuIGzJCosralsbtbHGUuXgaxk/edit?usp=sharing

Here’s a few resources about effective upstream contribution. It’s all content written by and for the Neutron community but it’s applicable to any OpenStack project.

• https://www.youtube.com/watch?v=ifBXiaFGry4 – “Land Your First Neutron Patch”, an OpenStack Paris summit talk by Rossella Sblendido
• http://www.slideshare.net/kevintbenton/how-to-get-reviewers-to-block-your-changes – “How to get reviewers to block you changes”, a hilarious OpenStack summit lightning talk with practical tips by Kevin Benton
• http://docs.openstack.org/developer/neutron/devref/effective_neutron.html – “Effective Neutron: 100 specific ways to improve your Neutron contributions”, a collection of best practices both technical and procedural written with blood by Neutron community members over the years