User talk:Dmose/Review System Priorities
Contents
Where are the review bottlenecks?
Super-review
I came to this page from the discussion on super-review policy for MailNews, so let me start with this item. I didn't experience the sr? handling as a major cause of delay over the last couple of years I've submitted MailNews patches, on the contrary, those came frequently much quicker than the actual r? feedback. Having a second set of eyes on a patch is quite helpful, especially in backend cases where consequences may not be as visible as with UI changes. Also, for shared code like Account Settings, it provides a vehicle to involve both Thunderbird and SeaMonkey devs to look over the proposed changes. --Rsx11m 02:07, 1 July 2010 (UTC)
UI-Review
You write that "the best proxy we have for things that are believed to be important for Thunderbird the product is patches that have ui-review+", where not all patches require ui-review to start with. Also, the ui-review itself sometimes poses a significant bottleneck, given that there is just a single reviewer for it with a usually long queue. Thus, sharing that obligation with at least a second reviewer may help reduce review times. In addition, some threshold when ui-review is required should be introduced, I'm frequently not certain whether or not it is needed (e.g., for typos or minor follow-up fixes on a patch which was ui-r+'ed already). --Rsx11m 02:07, 1 July 2010 (UTC)
Busy reviewers
Similarly, picking which reviewer may decide on when it will be reviewed, depending on the time available to the respective reviewer chosen. I'm not sure if it helps to have an "any" reviewer, thus whoever feels comfortable reviewing a patch and has time to do so can perform the review, or if this may lead to cases where a patch isn't taken by anybody as nobody has time, but just to throw this in as a possible idea. --Rsx11m 02:07, 1 July 2010 (UTC)
Which patches are important?
Some better metrics may be useful, but how to identify an "important" patch or - more precisely - "soon useful" patch? Coming into my mind are patches which are suitable and intended for the next dot-release, or patches with a simple fix but solving a rather visible issue, or those which will have a high impact. From the reviewer's point of view, they probably look all the same in the queue, maybe the bug summary or the patch description give a hint. I think it would help if patch authors could classify their patches in terms of target release (i.e., string changes or not), difficulty to review, and visibility or other impact significance, so that these factors are more obvious to the reviewer in order to set priorities. --Rsx11m 02:07, 1 July 2010 (UTC)
