"Rob Lanphier" <ro...@wikimedia.org> wrote in message news:AANLkTi=lgjrjj-gjx+_sdb0wpc62kptpoxbr7jkm8...@mail.gmail.com... > On Mon, Mar 28, 2011 at 7:20 AM, Aryeh Gregor > <simetrical+wikil...@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 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
