As we consider the value of super-reviews, we should include the
relationship between module owners and peers.
Long review queues are a burden for reviewers. Slow review turnarounds
force patch authors to juggle multiple patches to stay productive, but
this has a high context-switch overhead. Technical fixes are in the
works, such as new review tools and patch lint scripts, but we should
consider non-technical fixes, too.
Can we increase the number of reviewers by mentoring more developers to
become module peers, especially non-staff contributors? Review workload
would be balanced over more peers. We give more responsibility and
mentorship to developers, increasing knowledge and feeling of ownership.
This decreases the "[hit by a] bus factor" and grooms the next
generation of Mozillians. :)
Admittedly, increasing the number of module peers might require relaxing
the requirements for peers' module experience. For comparison, Facebook
is said to allow any developer to review any patch for any product.
However, Facebook's motto is "move fast and break things" and I am NOT
suggesting or endorsing that attitude for Mozilla. :)
chris
On 4/24/14, 4:51 PM, Gavin Sharp wrote:
We do have fairly clear rules:http://www.mozilla.org/hacking/reviewers.html
(The definitions of "Significant" and "API" are somewhat subjective, though
it's impossible to come up with completely objective definitions - IIRC
there were long newsgroup threads about this when this version of the
policy was created. Maybe more guidelines or concrete examples as part of
the policy would be useful.)
I agree with you that that policy isn't being followed our enforced
consistently across the project currently. "Every patch must have SR" was
an easy policy to enforce, this one is much trickier.
I don't frankly know how I feel about "the value of SR" today. I'm curious
what others think.
Gavin
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
