David Baron's Weblog

Bugzilla has long had a system where the priority of a bug is expressed as P1, P2, P3, P4, or P5. We haven't used this system very consistently in the past: any developer could prioritize his or her own bug list by setting priorities according to any criteria. Recently, though we've started using it for bugs that are blocking a particular release in order to prioritize those blockers. (As an aside, see my theory on what blocking really should mean.)

In any case, I've started trying to use the following priorities, even for bugs that aren't marked as blocking (although I still own bugs whose priorities are marked according to various other meanings, which I should probably fix). I think these are consistent with the way we've been using priorities for blocking bugs:

• 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.

That pushes a lot of bugs into the P4 and P5 buckets, but those are the ones that aren't going to be worked on all that soon anyway, and therefore they're the ones where the planning is likely to be redone before it actually matters.