24
edits
Platform/GFX/TriageSchedule: Difference between revisions
add note about triage leaderboard and management review schedule
(remove references to gfx-noted; we just need to set the priority now) |
(add note about triage leaderboard and management review schedule) |
||
| Line 6: | Line 6: | ||
=== Process === | === Process === | ||
* This is a rotating duty. Each individual will be in charge of a week worth of new bugs, assigned to nobody, starting Saturday, ending Friday. You would then have one extra week to act on them, so that a bug is at most 14 days old by the time somebody looks at it. | * This is a rotating duty. Each individual will be in charge of a week worth of new bugs, assigned to nobody, starting Saturday, ending Friday. You would then have one extra week to act on them, so that a bug is at most 14 days old by the time somebody looks at it. | ||
* There is a weekly Firefox management triage review on Thursdays. Ideally you will triage what you are able from your queue by end-of-day Wednesday to avoid us making the [https://are-we-triaged-yet.herokuapp.com/ leaderboard]. See the Pending Untriaged section. | |||
* At this pace, everybody will get this duty once per quarter. The schedule is in the shared calendar (see above), and it should be self-managing - if you want to trade your week with somebody else, you should be able to just move the item around. | * At this pace, everybody will get this duty once per quarter. The schedule is in the shared calendar (see above), and it should be self-managing - if you want to trade your week with somebody else, you should be able to just move the item around. | ||
* The goal is to make sure we don’t miss something important, completely or until “late”, and also notice any trends we may have with crashes or intermittent failures, or in any particular areas of the code. The idea is to categorize the bugs as they come in so that we know which ones need a jump on, which ones can wait a bit, maybe ask for some information that is missing, maybe CC the right people, etc. | * The goal is to make sure we don’t miss something important, completely or until “late”, and also notice any trends we may have with crashes or intermittent failures, or in any particular areas of the code. The idea is to categorize the bugs as they come in so that we know which ones need a jump on, which ones can wait a bit, maybe ask for some information that is missing, maybe CC the right people, etc. | ||