Bugmasters/Projects/Folk Knowledge/Priority Field
Contents
Mobile Frontend
Mobile Frontend team (Fennec, iOS) essentially don't use Bugzilla's priority field. Mobile team uses tracking-fennec flags to track releases; we assign individuals to track tickets; and we switch the status to ASSIGNED to mean "work is happening".
Some Firefox front-end teams use Bugzilla's "Rank" field to prioritize bugs from 1–60.
Priority-based triage
Some teams us the priority field to sort bugs.
- P1 - Fix immediately
- P2 - Needs to be fixed, but not urgent
- P3 - Would like to fix, but waiting for resources (optional)
- P4 - Not used or the same as P5.
- P5 - A real issue, but no intent to fix. (patches usually welcome)
Bugs without the priority field set are untriaged. Bugs that are not real issues are generally closed. The Media Playback team generally closes bugs that have gone several weeks without progress toward determining an actionable cause; most teams leave bugs open if the cause has not been determined.
The following teams use this workflow:
- Media Playback (Only P1, P2, and P5)
- Awesome Search Team
dbaron's schema
- P1: We can't ship an alpha/beta release (or, in particular, the next one) with this bug.
- P2: We can't ship a final release (or, in particular, the next one) with this bug.
- P3: I feel really bad about saying we're might ship a release with this bug still in it, but we might.
- P4: We should fix this as soon as we have the time.
- P5: It would be nice to fix this sometime.
Priority-based iterations
Used by the measurements client team:
- P1 - fix this in the current iteration
- P2 - would like to fix in this iteration if possible
- P3 - work-scope for this quarter
- P4 - longer-term work (year or so)
- P5 - valid bug but no intent to fix, patches welcome
