Some have suggested that we get clarification around where reviews should fall in this work order. Given the complexity of the decision tree, I'll just throw out a few questions that you can ask when you receive a review request.
1) Are you working on something urgently already (P1 or C2)? 2) Is the bug with r? milestoned outside C2 with a lower priority? 3) Can anybody with lower priority work than yourself review this patch? 4) Will the review take more than tens of minutes? If you find yourself answering Yes to a couple of the above, I'd suggest pawning the review off on somebody else if you've already got high priority work. If you're looking for suggestions of reviewers, please follow up with your manager. -Alex On Dec 3, 2012, at 8:08 AM, Alex Keybl <[email protected]> wrote: > [x-post to dev-b2g and dev-gaia] > > I'd like to clarify the work order we're looking for with v1 B2G bugs. > > 1) b-b+ and P1 priority with Critical severity (QA testing or dogfood > blockers) > 2) By priority, bugs marked with b-b+, the C2 milestone, and assigned to you > 3) Bugs marked with b-b+, the C2 milestone, and assigned to your team or in > your area of expertise (steal the bug, provide early feedback, review, etc.) > 4) C3 bugs marked with b-b+ and assigned to you, by priority > 5) Any other b-b+ bugs > 6) blocking-basecamp- bugs with a P4 priority ("soft blockers") - last > priority, if there is somehow no b-b+ bugs to work on > > If you have any questions, please let us know. If you've got a bug in that > 5th category that needs to be handled sooner, let us know so that we can > milestone it into C2. Thanks! > > -Alex > _______________________________________________ > dev-b2g mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-b2g _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
