Bug priority is not the same as bug severity. Bug priority talks about how important it is to fix a problem. The language of bug priority often deals with issues of image, marketing, shipping dates, importance to clients, importances to developer teams, how quickly patches should be made available, expected response times or similar.

An alternative for bug priority for setting the agenda in open source projects is often feature voting. A sample list of priorities might be:

• P1 - No workaround available, bugfix required
• P2 - Workaround in place, bugfix needed
• P3 - Workaround satisfactory, bugfix would be useful
• P4 - Bugfix would be useful
• P5 - Wishlist

Another one might be:

• P1 - It might seem minor to you, but the CEO said "fix it"
• P2 - If it's not fixed, several VPs jobs are on the line, and that includes you buddy
• P3 - Sales are falling, unless this is fixed, we might have to start patenting the suing people for revenue and go after SCO
• P4 - Customer reported the bug, please fix if they look like they might walk away from our product and stop giving us money
• P5 - It's an interoperability thing, we want to stay proprietory with vendor lockin, we're only logging this bug due to politics

(examples might be tongue in cheek - but the point is to emphasize the difference between bug severity being normally technical, and bug priority being social or political)

SeeAlso: Bug severity, feature voting

-- MS - 03 Feb 2004