A useful priority scheme might be, insert the ticket in the list of open tickets by urgency and importance. Something like that, that you can actually make arguments about and compare.
A useful priority scheme might be, insert the ticket in the list of open tickets by urgency and importance. Something like that, that you can actually make arguments about and compare.
We start out with some sensible definition of priority for bugs: P3 = nice-to-have, P2 = low-priority-but-ship-blocking, P1 = emergency-fix-this-now. Bug intake goes on for a while under this system. Some bug filers don't feel their P3 or P2 bugs are getting worked on, so they "promote" those bugs to P2 and P1. That'll show those engineers my bug is important! Now we seem to have more and more P1 emergencies going on, and the team is struggling to just get through those. Nobody knows which ones are actual emergencies, and which ones are just "somebody being passionate about a bug".
Soon, we get an actual pants-on-fire production emergency. This emergency is more urgent than any P1, so we call it P0! Now we finally have a way to mark real emergencies, because the bug database is now overflowing with P1s. Soon people realize they can deem their favorite bugs as really-really-important, so they promote them to P0. Eventually, the database is now overflowing with P0s, and nobody knows what's really urgent. Then another real pants-on-fire production emergency happens...
1) Allow developers to change the priority, i.e. downgrade P0 to P1 or P2, with all subscribers notified. Optionally, always downgrade to the lowest possible priority.
2) Shame people for inappropriately using P0. After a few strikes, remove their ability to do so.