Priorities

When using any issue tracking software, it's important to know which issues should take priority. Issues that are high priority should, obviously, be dealt with first. Issues of lower priority can wait.

Usually, this means assigning a number to a particular issue, perhaps with a descriptor of some sort. Some go from one to ten, some go from one to seven. They might go from "Must fix" to "Don't Fix". This is, however, not always intuitive. What does a six mean? What does a one mean? Are people just going to mark everything as a 10? Does the description of the issue say "Not a huge priority", but the rank says "Must fix"?

If you couldn't tell, I've had some bad experiences with priority systems.


But I think I've found a way that might work. For Slick Text, we use Git Issues, and I've set up some simple labels. There four "issue type" labels, and three "priority" labels. We'll start off with the "issue type" labels:

• Bug
• Feature
• Enhancement
• Question

Pretty simple. Pretty straightforward. From the standpoint of a developer, we'll often be paying attention to the bugs, especially if they happen to be in production code. But maybe not. Maybe it's just not a very high-priority bug - perhaps one that affects a feature that doesn't get much use, and maybe a feature or enhancement is most important right now.

The point is that you can't tell which issues are high priority from these labels. Hence, we assign a priority. Numbers, for me, haven't worked in the past. Neither have "must fix" "don't fix" "might fix", etc. So, I devised something a little simpler - a little more visceral and intuitive. Here they are:

• Now
• Soon
• Later

If you don't immediately get that, then I can't help you.

I think this is a good solution, because it provides some sense of urgency without using overly strong language. It's perfect for a small, casual startup. "Now" basically means "as soon as possible", but without the scrambling, pressure-ridden, negative connotations of "ASAP".

"Soon" is sometime after "Now".

And "Later" is sometime after "Soon".

If an issue won't be dealt with, then it shouldn't exist. It should be closed, instead of labeled with a "Won't fix" or "Don't fix".

Obviously, this won't work for every developer, and it won't work for every team. But so far, it's worked for us. Give it a shot.