[webkit-dev] Review Queue

[Nikolas Zimmermann]

Am 22.05.2009 um 06:41 schrieb Maciej Stachowiak:

>
> On May 21, 2009, at 9:18 PM, Ojan Vafai wrote:
>
>> It makes no sense to me to r- a patch because reviewers don't have  
>> time to review it. It put incentive in the wrong place. There are  
>> other solutions to this problem that put incentive in the right  
>> place (i.e. with reviewers). I don't necessarily think these are  
>> good ideas, but I'll throw them out there.
>>
>> 1. If the review queue gets too large, close the tree to commits  
>> until the queue is at 80% of that too large number.
>> 2. Automate landing commits (e.g. click a button off the commit  
>> queue) so that it's easier to land commits and keep the commit  
>> queue small.
>> 3. Give some kind of very visible notice on the waterfall when the  
>> review queue gets too large (e.g. make the background color of the  
>> whole page red).
>> 4. Auto-assign reviews that haven't gotten reviewed after two weeks  
>> to a reviewer and have that person be responsible for reviewing it  
>> in a timely manner (this gives personal responsibility over the  
>> queue length instead of the current distributed responsibility).
>>
>> I'm sure there are a ton of other possible solutions to this  
>> problem that don't punish people sending patches who have little  
>> control over this situation. I imagine doing 3 and 4 would make a  
>> significant difference.
>
> I discussed the review backlog with Mark Rowe earlier, and we came  
> up with another idea that may help. This would be to categorize the  
> review queues. Perhaps we could get bugzilla to show a separate  
> review queue per component. So for example there would be queues for  
> "CSS", "JavaScriptCore", "WebKit Qt", etc. Then we could assign  
> specific people to be responsible for that queue. That doesn't mean  
> these are the only people who can review, but we would know who to  
> badger if certain queues get backlogs.

I think this is a very wise idea. If we'd combine this with a "review  
queue supervisor" per component it with certainly help to avoid  
backlogs.
For instance the supervisor could get a mail all two weeks listing the  
patches waiting for review. Either the supervisor takes care of the  
review
or delegates to other reviewers. The idea is that at least someone  
notices the queue is very long. The last times this came up on the  
mailing list
I think it was either Eric or Maciej notifying the crowd about the  
state of the review queue. This definately needs to be changed.

So, you get my voice for creating categorized review queues. The  
positive side-effect is that I don't need to scan long time for  
patches that interesst
me (aka. that I'm qualified for review), but rather get the list of  
patches immediately in a single view.

I think it's great that Eric brought up this topic again, as I think  
we can improve the situation much better with not that much effort.

Have a nice day,
Niko

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090522/d5b7424a/attachment-0001.html>