I've talked about the difference between priority and severity and proposed possible severity levels. Here's my current thinking on priority levels in issue tracking systems for software development (and specifically Leonardo's Roundup tracker).
Most systems I've seen simply use numbers for priorities: P1, P2, P3, P4 and P5, for example. To really know which one to use, groups end up assigning particular meaning to them.
Outside of software development, I've found it useful to think of priority in terms of modals like:
and, where appropriate adding things like:
I think it's useful in software development to think of those modals in the context of releases. e.g. this bug must get fixed for 0.5 or that enhancement should get in 0.6.
This is already better than P1-P5 but there are some complications that need to be addressed.
Firstly, if one assumes that maintence patches are still taking place on previous releases, it is possible for issues to have priorities relative to multiple releases. For example, a bug might be a "must for 0.5" and a "should for 0.4.1". How would one express that in an issue tracking system?
Secondly, one probably needs finer grained priorities on occasions when, of the 20 things that must or should get into the next release, there are 5 that must get done in the next week and another 5 that should.
The second is less of an issue for Leonardo in my opinion, but it would still be nice to address.
One way of addressing the former, especially if one assumes that one is only actively maintaining one version prior (reasonable at this stage of Leonardo at least) is to have separate priority fields: one for the upcoming patch and one for the upcoming new version.
So both "patch priority" and "trunk priority" could have values like:
What priorities have others found useful?
The original post was in the category: software_craftsmanship but I'm still in the process of migrating categories over.