For your information. The thread about our Gerrit review queue metrics is continuing in wikitech-l under http://lists.wikimedia.org/pipermail/wikitech-l/2014-April/075635.html

---------- Forwarded message ----------
From: Quim Gil <qgil@wikimedia.org>
Date: Thursday, April 3, 2014
Subject: Data to improve our code review queue
To: Wikimedia developers <wikitech-l@lists.wikimedia.org>


Please have a look to some graphs visualizing interesting data from our code review queues in Gerrit, focusing in the key Wikimedia software projects.[1]

http://korma.wmflabs.org/browser/gerrit_review_queue.html

The queue of open chagesets keeps growing. We have open changesets submitted in every month since March 2012. However, since last December we must be doing something right, because the median times to update and resolve submissions are decreasing.

Looking at http://korma.wmflabs.org/browser/scr.html , one reason for this improvement might be that the volume of new changesets has also decreased during the same period. Maybe newer patches get faster reviews? Any ideas? We need to dig further.

We have created a "hall of shame" (add you preferred smiley here) to bring under the light the repositories with the open changesets that haven't seen any activity for a longer period. The principle is simple: you don't want to see one of your repos appearing in the top 10.

Many of the _leading_ repos have a couple of open changesets only, and our hope is that by showing up there, the maintainers will act on them quickly (e.g. OpenStackManager, fluoride, commons, UserMerge, TorBlock, Vipscaler, luasandbox...). This will leave the fight for the pole position to the projects that actually have a real problem dealing with patches received (Donationinterface, GuidedTour, UploadWizard...)

Who knows, perhaps we should organize "patch days", in the same way that we have organized bug days in the past (which we want to recover now). We also want to look at ways promote the oldest inactive requests. For instance, what about directing new volunteers there, asking them to submit their code revisions. For a patch that has been waiting in silence for over a year, any feedback will be better than no feedback.

One last detail. Our initial motivation to look at the age of open changesets by affiliation was to check whether submissions from WMF employees and independent developers were treated equally. Interestingly, there are no big differences between these groups. However, there are big differences between the median age of open WMDE changesets (16.5 days) and open Wikia changesets (almost 283 days). All this according to our estimation of the origin of patches (domain of the submitter's email + affiliation submitted by the developers that filled our survey.[2]

Your feedback about these metrics is welcome. Please reply here or file Bugzilla reports directly to Analytics > Tech Community metrics

https://bugzilla.wikimedia.org/buglist.cgi?component=Tech%20community%20metrics&list_id=297881&product=Analytics&resolution=---

(Short link just in case: http://bit.ly/1q0itsl )

[1] https://wikitech.wikimedia.org/wiki/Key_Wikimedia_software_projects

[2] https://docs.google.com/forms/d/1RFUa2zBAOolw78W-ozJPoYlR2lYbrAOYvOZYgjaAYQg/viewform

--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil



--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil