Thank you for posting this Erik.
I initially didn't reply on this thread because to me it just seems to
be the same as the 3 or 4 times we've had the same discussion before.
No technical or procedural change is going to solve a problem that is
ultimately caused by a lack of time assigned to it. I was somewhat
disappointed by the suggestion that the onus should be on volunteers to
find a reviewer for their code, as this is just as unworkable without
staff time assigned to doing it - and perhaps could be even more
demotivating than the status quo.
Having review be a portion of staff time was always how I assumed it
would be arranged. The justification for not assigning time to review
has often been that one person or team doing it all the time would
result in burn-out, and I agree with this. As a (part-time) developer I
certainly wouldn't want to spend all my time doing service work, even
for just one or two weeks at a time. The idea of having a single
person/team assigned for each deploy/release cycle is nice, but I think
that it would lead to burn-outs and conflicts with existing
responsibilities those people have. Whatever model is implemented, I
hope it can finally be successful.
I reject the notion that we need a change in our review processes.
Empirical evidence shows that when staff time is assigned to it, our
code review system *does* work. (Of course there are always minor
changes that would improve efficiency, such as automating some of the
reporting tasks that have traditionally been done manually.)
Updates on how this is going would be nice, as again it took MZMcBride
to bring it up before anyone senior posted about it - and this is still
the big issue for volunteer developers.
Cheers,
Robert
On 2011-06-01, Erik Moeller wrote:
On Wed, Jun 1, 2011 at 4:50 PM, Brion Vibber
<brion(a)pobox.com> wrote:
This is one of the reasons I tend to advocate
shorter
development/review/deployment cycles. By keeping the cycle short, we can
help build up regular habits: run through some reviews every couple days. Do
a deployment update *every* week. If you don't think your code will be
working within that time, either work on it outside of trunk or break it up
into pieces that won't interfere with other code.
With a long cycle, review gets pushed aside until it's no longer habit, and
gets lost.
Right. And just to weigh in quickly on the resources issue -- the
review/deploy/release train is clearly not moving at the pace we want.
This does affect WMF staffers and contractors as well, but we know
that it's especially frustrating for volunteers and third party
committers. We kicked around the idea of a "20% rule" for all funded
engineers (IMO not just senior staff) in Berlin and in the office
yesterday, and I think Roan mentioned it earlier in this thread: i.e.
ensuring that every WMF-funded engineer spends one day a week on
"service" work (code review, design/UX review, deployment, shell bugs,
software bugs, bug triaging, etc.).
An alternative model is to have rotating teams that do this work. I
personally prefer the 20% model because it gives more
consistency/predictability and less churn, but I'm curious what other
folks think, and I'm comfortable with us continuing this discussion
openly on this list.
Whether that would get us to a healthier balance remains to be seen,
but I think there's pretty broad agreement that adding more support to
the review/deployment/release process is a necessary precondition for
any other process changes like moving towards pre-commit review.
Clearly what's been said in this thread is true -- there are lots of
things that can be done to reduce our technical debt and make it
easier to accommodate and manage new changes, but without added
dedicated capacity, the train won't move at a speed that we're happy
with. We can't change that overnight (because we need to figure out
the right rhythm and the right processes together), but we will change
it.
Erik
--
Erik Möller
Deputy Director, Wikimedia Foundation
Support Free Knowledge:
http://wikimediafoundation.org/wiki/Donate
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l