Skip to main content
Jump to: navigation, search

WTP/Conventions of bug priority and severity

Revision as of 00:26, 4 September 2009 by David (Talk | contribs) (initial draft)

This document is to expand on the meanings of Priority and Severity in bugzilla, as those fields are used in WTP, by convention.

These fields are important to "get right" for many reasons. For one, it helps make sure important bugs are not "lost" in the chaos of a release. Also, for people who open bugs, it is important to be accurate so their reputation of "providing good bug reports" is untarnished. Let's be honest ... someone who repeatedly opens bugs as critical which are not critical (by our conventions) begins to be treated as The Boy Who Cried Wolf.

As stated in the Bug Reporting FAQ

Severity is assigned by a user and describes the level of impact the bug is having on them. Priority is assigned by the developer and describes the importance a developer places on fixing the bug. P1 is the highest priority, P5 is the lowest.

Bugzilla's own documentation gives a general definitions of priority and severity which is pretty much what we follow in WTP. But below is additional information that will hopefully provide guidance for more consistent use.


Priority Standard Bugzilla definition WTP convention
most important
Must fix for next release. Literally. We will slip dates for P1's, so use sparingly.

Very important for next release. Nearly all P2's should be released, so do not over use.

Of normal importance. Default starting point. Once a bug is triaged, it should have an accurate priority.

Important, but less so. Would expect to be fixed someday.
least important
A valid bug, but no plans to investigate or fix. All 'P5' bugs also imply "helpwanted", but "helpwanted" can be used on any other priority.


Severity Standard Bugzilla definition WTP convention
Blocks development and/or testing work.
Same meaning in WTP. Notice it would be very rare for an end-user to have a 'blocking' bug. This isn't the common English definition of "blocks me from getting my job done" but blocks adopter development or adopter testing. Also note: if there is any workaround found for a blocking issue, then it is no longer blocking and severity field should be corrected.
Crashes, loss of data, severe memory leak.
critical refers to the impact of the bug, not its importance to the originator (use votes and prose comments for that).
Major loss of function.
Major' is the severity to use when something seriously gets in the way of getting your work done. For example, can not run on server, no content assist at all.
Regular issue, some loss of functionality under specific circumstances.
Same meaning in WTP. This is default severity. Use it if you are not sure. This is also the priority to use if there is an error in one of our APIs (e.g. incorrect parameter) or an error in what is documented for the API (e.g. returns null even though documented not to return null).
Minor loss of function, or other problem where easy workaround is present.
Problems which are worth reporting (and fixing) but do not really interfere with normal work or use.
Cosmetic problem like misspelled words or misaligned text.
Not often used. Most cosmetic problems in WTP are considered at least 'minor bugs. A good use, though, is to note things like spelling mistakes in JavaDoc.
Request for enhancement.
Use this to mark requests for completely new things. Sometimes there's a grey area between what's "completely new" versus "missing what was expected". The later could be considered a 'normal' bug, so if really was expected and wasn't there then open as a 'normal' bug and committers will say if it really should be an enhancement request.

Back to the top