-
-
Notifications
You must be signed in to change notification settings - Fork 117
Issue Priority Categories
| Indifferent | Wanted | Desired | |
|---|---|---|---|
| Important | (Refactor) | (Stability) | (Killer feature) |
| Good | (Cleanups) | (Task) | (Enhancement) |
| Chore | (Obscure) | (Niche) | (Disruptive) |
There are many ways to classify the "priority" of an issue, and often this is represented using more than one dimension. Analogies include risk vs impact, priority vs severity, although the literature seems to be unclear on the latter. There are many other dimensions, some which tend to be correlated. Rather than reflect them all or squish them into one "priority" dimension, I would go with two, focused on two perspectives: the wants of users, and the wants of developers.
Users want to improve their experience, whether that's fixing visible bugs or adding fun features. There are at least two dimensions to this however; how badly does an issue affect user experience, and how widespread it is. It could be a severe bug that affects a tiny minority, or a widespread bug that's only an inconvenience.
Developers on the other hand want different things to users. Of course most developers tend to be users as well, but for the developer role, they want to work on issues that are easy, improve code quality, or are fun to work on. Unfortunately these aspects are quite different, so there aren't many good words to describe this aspect as a whole; one label could be "importance". A good example of an issue that is "important" but insignificant to user experience would be code refactoring. Whilst one may argue that refactoring helps future work, the issue itself has no direct impact on user experience.
There's an important third role that's not quite user and not quite developer: modders, or 3rd party creators. They may want certain user features, not even modding-specific features, to improve what they do. They may also want certain improvements that are otherwise invisible to normal users, but will help them and normal developers alike. Modders would need to be treated as a separate class of stakeholder.
It's not clear whether the "desirability" vs "importance" dimensions should be comparable to each other, e.g. how to rank a desirability 1 (highest) importance 3 (lowest) issue, against a desirability 2 importance 1 issue. One may argue that they should be combined, since it considers the needs of both users and developers. What's clear is that if, for example, two issues have the same desirability, then the most important should have higher priority.
It's important to consider the exact viewpoints involved when assessing the desirability or importance of an issue. An easy trap is to assess an issue as important because a developer "wants" to resolve an issue, but they may have wanted it from a user's perspective - i.e. they want it resolved so their user experience is improved. A converse trap is to assess an issue as desirable, because it introduces a fancy new feature, but really it's "important" as it involves a fancy new algorithm, and the feature itself is seldom used. As a guideline, here are some labels that correspond with the dimensions (to be clear, not all of these labels are orthogonal with the other dimension in practice):
Annoyance, severity, impact, popularity, user experience, speed, smoothness, features, user interface
Ease, code quality, cool, fun, itch, technology, algorithm, standards