This may be a controversial opinion but I strongly disagree with using bug priority/severity/urgency/impact etc to do work prioritization. I think there are tw

This may be a controversial opinion but I strongly disagree with using bug priority/severity/urgency/impact etc to do work prioritization. I think there are two separate things about tickets: one is the about technical merit of a ticket: documentation, evidence, reproducer, quick info about context. Basically, a ticket as a tool to gather and sort "technical discussion". This is fine and encouraged. Then there is the "priority" - I don't think is a feature of a ticket. It's a property of context - do users complain _now_? Is the fix risky? Is the boss shouting? Do we lose money? Does the PM want this work done for personal reasons? How much time will it take for me to do a context switch to start the work? I don't think it's possible to add this "priority" (as defined by social interactions) to a ticket. I always found I prioritize tickets that I understand the social context of. A colleague nagging me by walking to my desk is 100X the priority for me than "P1 critical" written by some PM on the other side of the planet. The point: I try not to fight with the social aspect. If you want me to do a ticket. Good. Come over. Do a hangout and explain the context. Setting a mindless value in some field on some random badly described ticket is not going to make me de-prioritize other things.