Bugmasters/Projects/Folk Knowledge/Priority Field

Mobile 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 2009 blog post about Bugzilla priorities

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