- 1 Overview
- 1.1 New bugs of "defect" or "task" type - do this daily
- 1.2 Unanswered-needinfo new defect bugs - do this weekly
- 1.3 S1 bugs (including defect, task, enhancement) - do this weekly
- 1.4 Severity/Priority nomination
- 1.5 Bugzilla Query List
- 1.6 Chipping away at bugs that may have been forgotten - doesn't have to be done daily
- 1.7 References
Here gives an overview of how we do triage and what each priority means. We now have three types of bugs: defect, task and enhancement. Our engineering daily triage practice focuses on defect and task bugs. Bugs with type task or enhancement will generally be reviewed with PM/EPM. The goal is to set a Severity in as little time as possible and to drive timely actions for important bugs.
As of the new Mozilla triage practice starting in May 04, 2020, we set the Severity field to a non-default value when triaging Firefox related bugs.
New bugs of "defect" or "task" type - do this daily
New bugs of "defect" or"task" type that need actions
- DOM Fission (needs update per the new "Severity triage" practice)
- DOM Workers & Storage(needs update per the new "Severity triage" practice)
Each day, for each of the bugs in the lists above, set the Severity field and ensure the one or more current (Nightly, Beta, Release, ESR) Status_FirefoxNN flags set to a non-default value for a "defect" bug:
- S1: (Catastrophic) Blocks development/testing, may impact more than 25% of users, causes data loss, potential chemspill, and no workaround available
- S2: (Serious) Major Functionality/product severely impaired and a satisfactory workaround doesn't exist
- S3: (Normal) Blocks non-critical functionality and a work around exists
- S4: (Small/Trivial) minor significance, cosmetic issues, low or no impact to users
Use these descriptions to guide your decision on a bug’s severity. We’ll be mapping existing bugs to the new definitions.
Let's ensure newly-filed bugs in a variety of DOM-ish components are actionable as soon as possible after their filing. This doesn't mean we're going to fix them sooner but that they'll be fixable when we get around to attempting to fix them.
- is this bug with the right type?
- is this bug in the correct component?
- do we need a regression range?
- needinfo for more information, e.g. URL, STR, or module owners' comment, if you can't decide the severity (and priority) right at the moment
Unanswered-needinfo new defect bugs - do this weekly
We'd like to see needinfo answered in 10 days.
- is there an outstanding needinfo request for any missing information?
- is there someone else who could answer?
- is there a more appropriate person to needinfo?
- see above for other tips for dealing with new bugs
- do these people or their managers need to be emailed?
- Set severity if you've done above and there's no pending needinfo so it doesn't show up in tomorrow's list
Bugs with outstanding needinfo?
- DOM Core needinfo? (all types)
- DOM Fission needinfo? (needs update per the new triage practice)
- DOM Worker&Storage needinfo? (needs update per the new triage practice)
S1 bugs (including defect, task, enhancement) - do this weekly
- is there is an assignee?
- is there anything needed to make this bug move forward?
- is this still a valid S1?
- DOM Core S1s
- DOM Fission P1s (needs update per the new triage practice)
- DOM Worker&Storage P1s (needs update per the new triage practice)
Make severity changes after review. (De-)Nomination happens at least once a release.
- are any of these super sever and thus really S1?
- if we marked something as S2 and it's been that way for a while, do we really need to keep it as such or could it become a S3?
- is a bug even valid anymore?
Bugzilla Query List
Other useful ones:
- DOM Core New WPT failures, including which passed before but fails recently, or which passes on other browsers but fails only on Firefox. These bugs are excluded from the daily triage practice. It's good to review it regularly (e.g. monthly) as it can be a useful input to understand our interoperability situation and to prioritize the future work.
Chipping away at bugs that may have been forgotten - doesn't have to be done daily
- is there anything needed to make this bug actionable?
- is this bug being prioritized appropriately?
- is this bug even valid anymore?
Old bugs that need re-prioritization or re-validation
Blink's Triage Best Practices document is a nice read