<div dir="ltr">Er, sorry, the previous email just left my mailbox too fast.<div><br></div><div>The proposal below has a related Phabricator task: <a href="https://phabricator.wikimedia.org/T101686">https://phabricator.wikimedia.org/T101686</a></div><div><br></div><div><a href="https://office.wikimedia.org/wiki/Health_check_survey_results/FY2014-15_Q3">https://office.wikimedia.org/wiki/Health_check_survey_results/FY2014-15_Q3</a> indicates a growing concern about code review. Our code review queues keep growing, I'd say still faster than our concerns, and this trend can only lead to some variation of *collapse*.</div><div><br></div><div><a href="http://korma.wmflabs.org/browser/gerrit_review_queue.html">http://korma.wmflabs.org/browser/gerrit_review_queue.html</a> shows these monthly snapshots of open chagesets waiting for review (-1 and work in progress are not counted):<br></div><div><br></div><div>May 2013: 250</div><div>May 2014: 1033</div><div>May 2015: 1549</div><div><br></div><div>In order to stop this trend, revert it, and clean our queues we need a radical change. I want to propose a basic principle that should guide our software development practices:</div><div><br></div><div>"A team should review their open patchsets before writing new code."</div><div><br></div><div>This is not impossible, just a matter of setting priorities. Exceptions could be made as long as their queue of contributions waiting for review is diminishing. The average reviews should probably be harsher, not hesitating to give a -1 and a short explanation that brings the initiative back to the original uploader, or a -2 and another short explanation when patches are just too bad or not compatible with the scope or roadmap. Any of these measures would be better than an ever-growing queue of languishing patches.</div><div><br></div><div>This principle would also help highlighting deeper problems, mainly repositories and whole areas of code that are unmaintained in practice. Knowing these areas, we could decide to either allocate/empower new maintainers, or just put a big banner indicating that "Sorry, this repository doesn't welcome new contributions as we are not able to process them adequately", or, again, something better than just let patches rot in silence.</div><div><br></div><div><br></div><div><br></div><div>PS: I'm sending this email to team-practices and not wikitech-l because this is a matter of team practices and team management in the first place; pinging individual developers as some of us do in Gerrit sometimes is just not enough.</div><div><br></div><div><br></div><div><div class="gmail_extra"><div class="gmail_quote">On Mon, Jun 8, 2015 at 10:23 AM, Quim Gil <span dir="ltr"><<a href="mailto:qgil@wikimedia.org" target="_blank">qgil@wikimedia.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Thank you, very useful. I'm happy to see that our problem with code review keeps becoming more evident, if only as a step to finally doing something about it.<div><br></div><div><a href="http://korma.wmflabs.org/browser/gerrit_review_queue.html" target="_blank">http://korma.wmflabs.org/browser/gerrit_review_queue.html</a> shows that our backlog of patches waiting for review keeps growing. 1542 last month, was 1033 a year ago. If you consider the time and skills it takes to produce one patch, you may imagine the big black hole of frustration and waste of real money we have there.</div><div><br></div><div>While comparing satisfaction across teams is subjective and complex, comparing code review waiting times between WMF teams can be measured objectively. Engineering Community is aiming to organize a first Gerrit Cleanup Day [1] focusing on open patches submitted by volunteers, and we could work on these metrics for the second one -- unless someone wants to start earlier, of course.<br></div><div><br></div><div>[1] <a href="https://phabricator.wikimedia.org/T88531" target="_blank">https://phabricator.wikimedia.org/T88531</a></div><span class=""><font color="#888888"><div><br></div></font></span></div></blockquote></div>-- <br><div class="gmail_signature">Quim Gil<br>Engineering Community Manager @ Wikimedia Foundation<br><a href="http://www.mediawiki.org/wiki/User:Qgil" target="_blank">http://www.mediawiki.org/wiki/User:Qgil</a></div>
</div></div></div>