"Rob Lanphier" <robla(a)wikimedia.org> wrote in message
news:AANLkTi=LGJRJj-gJX+_Sdb0wpc62KPtpoXbR7JkM8AB6@mail.gmail.com...
On Mon, Mar 28, 2011 at 7:20 AM, Aryeh Gregor
<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
The fact that this is a very reasonable (and clearly genuine) problem makes
is *more* concerning that it's being "danced around", not less. If this is
a problem, then it needs a solution, because it sounds like we're not going
to make much headroad into the larger issues without it. What solution do
you propose? Greater focus amongst junior devs? A Mozilla-style
'review'/'superreview' model? Even "all the junior devs going away
and
leaving the senior devs in peace" is *a* solution, although I'm sure that's
not the preference given that most of our senior devs were once junior devs.
But something has got to change, one way or another. Because only about 3%
of the past 500 reviews have been done by permanent staff, and commits are
still accumulating around 20% faster than reviews, in bulk. What's the
plan...?
--HM