No doubt that things do not always go smoothly in practice. :) I was describing the ideal that we should be striving for, and the general process we should use to address problem cases (which will inevitably occur).
As you point out, "escalation" can have some negative connotations, but it doesn't need to be negative. This is all about communication, and raising the issue (with the person, or the module owner, or some other technical leader) is less about assigning blame or "getting someone in trouble" and more about constructively pointing out the problem and pointing out that a solution is needed. People in the escalation path have a responsibility to help, and are generally aware of that responsibility and willing to help. Note that the "I'm overloaded" case you mention can be addressed by just communicating that clearly to the review requester (as bz or smaug sometimes do). A review request requires a prompt response - but that response does not necessarily need to be a code review. It can also be "Sorry, can't review this soon, please find someone else". Clearly, if there is no one available and able to review a particular patch and someone is blocked on that, that is a separate problem that also needs to be addressed. This case might have a slightly different escalation path, depending on the situation. If you are a MoCo employee, you have further recourse of being able to talk to your manager, who can help ensure that you aren't stuck working on un-owned code alone. Your point about needing to broaden the pool of reviewers is a good one too. I think everyone supports that in the abstract. Let's "make it real" - identify the places where we want to invest in fixes, but where we're lacking in reviewers, and let's get some peers/reviewers added to those lists. I'm happy to help. Gavin On Thu, Mar 19, 2015 at 3:46 AM, Gabor Krizsanits <gkrizsan...@mozilla.com> wrote: > On Wed, Mar 18, 2015 at 4:47 PM, Gavin Sharp <ga...@gavinsharp.com> wrote: > >> This is a difficult problem to discuss in the abstract. >> >> It should never be the case that you are "waiting for weeks/months" - >> you should either be getting reviews within a week (at worst), or be >> getting responses saying "can't spend time reviewing this now". Where >> that is not happening, the escalation path should be something like: >> > > If it never happened I would not have written this email. But I agree it > should not. > It's a very nice gesture that someone at least reacts on the request and > tell me > an ETA or gives me a heads-up about the delay, and I can just encourage > people > to do so, but that does not fix the issue. And escalation can cause more > trouble > sometimes than it helps... > > Let's say I'm at the other side, and all of a sudden I have to review > dozens of huge > patches I have not seen coming, while I'm working on P1 sec. crit. > blockers, or > have 100 other patches to review, what can I do? But let's forget about > extreme > cases and long delays for a second... > > I've seen core developers on bugzilla closing their review queues... Example > could be smaug or bz, who probably have more reviews to do than I could > count. > I seriously have no idea how can they do any other work. All my gratitude > for their > amazing job with reviews, and juggling with all the things they do at once. > It's > incredible to me that someone can do 100 reviews a week... I just think it > would > be nice if there were more people who could lift off some reviews from their > shoulders. Might be a stupid idea... Based on the reactions, or the lack of > them > probably it is. > > - Gabor > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
