What's a priority but a way to decide what to do next? The fact it's stored as a label on a ticket doesn't seem particularly relevant.

The discussion over what priority label to put on a ticket has very rarely changed my opinion on what the actual importance of the ticket is, and I'm generally going to pick what to work on based on that, not based on the label.

Absolute priority quickly becomes washed out - everything gets shoved to one end of the range.

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.

Almost every software company I've ever worked with had this insidious "priority inflation" that couldn't be stopped. It works like this:

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

I worked at a shop with P0, and then there were too many P0 tickets, and then you just worked on whatever the CTO told you was the _actual_ highest priority ticket when he stopped by your cubicle for a chat.

No one got fired for making something a P0. That's the problem.

Seems like an easy fix.

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.

It is a way to categorize tickets. It somehow influences what is going to be done next, but it is only one of many factors.

One project manager in our company started to actually use it for prioritization, the higher the priority the sooner it was done. Soon after, literally everything ended to labeled critical.

People shouldn't be able to label their own bugs/features' severity or importance. They should be able to label it with severity or importance to them, and the team responsible should be allowed to triage accordingly.