The priority of code review (Re: Code Review tools) - Wikitech-l

28 Mar 2011

On Mon, Mar 28, 2011 at 7:20 AM, Aryeh Gregor &lt;Simetrical+wikilist(a)gmail.com
...
  wrote: 
...
  If, as Tim says, Wikimedia developers were un-assigned
from code
 review after the 1.17 deployment, *that* is the problem that needs to
 be fixed.  We need a managerial decision that all relatively
 experienced developers employed by Wikimedia need to set aside their
 other work to do as much code review as necessary to keep current.  If
 commits are not, as a general rule, consistently reviewed within two
 or three days, the system is broken.  I don't know why this isn't
 clear to everyone yet. 

Hi Aryeh,

You say that as though this were obvious and uncontroversial.  The reason
why we've been dancing around this issue is because it is not.

Right now, we have a system whereby junior developers get to commit whatever
they want, whenever they want.  Under the system you outline, the only
remedy we have to the problem of falling behind is to throw more senior
developer time at the problem, no matter how ill-advised or low-priority the
changes the junior developers are making.  Taken to an extreme, this means
that junior developers maintain complete control over the direction of
MediaWiki, with the senior developers there purely in a subservient role of
approving/rejecting code as it comes in.

What comes of this system should be obvious: senior developer burnout.  If
only reward we offer for becoming an experienced developer is less
interesting work with less power over day-to-day work, we're not going to
attract and retain people in senior positions.

To be clear, none of the developers in WMF's General Engineering group have
been pulled off of code review.  However, not all of the WMF's senior staff
are part of GenEng.

Rob