Unfeature 2: Prioritizing   by Ryan

Our last unfeature was a big one, but the conclusion was a bit hand-wavey — we don’t have an API yet!

This time we’re going to keep it a bit more real and talk about priorities.


Most todo oriented software has the concept of priorities. High priority, very high priority, the highest priority. We think that sort of thing is an awful idea. Merlin Mann went in depth on the subject of what priority really means in 2009.

It’s always hard to argue with Merlin, and in this case there’s nothing to do but quote him:

A priority is observed, not manufactured or assigned.
Otherwise, it’s necessarily not a priority.

This is exactly how we approach bug and feature todos on a daily basis. Either this is a priority, or it isn’t. If it is a priority (and there tends not to be much debate on whether it is or not) then it is hardly even useful to mark it as such in your bug tracker. Just do it immediately!


Now, it could be that ‘priority’ is simply a misnomer — that what we really want to do is rank things just to keep them straight in our heads. We want future-us to be able to remember what was going on. That’s fair enough. Maybe you just need to mark a ticket: “this one here is kind of a big deal”, or maybe the opposite, “if this one has to wait until next month, well that’s just fine.”

Completely banning priorities is a bit draconian since we don’t necessarily know why this one is important to you. That actual high priority thing you just dropped everything for? — You probably want to record it at some point and put on record the fact that it was a fire. A nice-to-have that no one will cry over? — Get it in the bug tracker quick or you’ll forget all about it.

That doesn’t mean we go overboard with every conceivable option, though.
Ultra Super Important vs non-ultra Super Important vs Sorta Important vs ...


In the end, Bugrocket is about making the bug tracking developers do every day less frustrating by having a purposely small feature-set. What we don’t do is cut things that those same developers need. So we sat down and figured out the smallest thing we could do to get the job done. It’s obvious, once you see it:

That’s right. The left one there is low, not important for whatever reason. The middle one (and the default) is normal, nearly all of our bugs use this setting. And lastly high, for indicating this one is a VIB™.