issue tracking

When designing the classification for our bugtracker, I tried to be very conscious of the purpose of each field. Here's what we ended up with.

When are we going to work on it?

This field records the results of our planning. It's very useful to search and filter on: when a developer is out of tasks (everything assigned to him is done, or his work is blocked for any reason) he can just grab an issue from the list of all unassigned bugs sorted by "When":

We frequently move issues between "Now" and "Next", and review the "Soon" tasks from time to time and after a release. Occasionally we go through the "Later" tasks. "If ever" is the field we use instead of closing requests we aren't sure we're ever going to work on.

How long is this going to take to fix?

This field is our best estimate of how long the work is likely to take. It is notoriously hard to have an idea of this, but due to the logarithmic scale and order-of-magnitude roughness we are rarely off by more than one entry in this list:

This field is used in several circumstances. First and foremost, it is a major consideration as to what goes into the "When" field discussed above. I like using this field to pick a very short task to start with on a Monday if I'm not feeling too motivated. It's also useful to find work for a new employee or someone else who's not feeling motivated.

How important is this task, in the grand scheme of things?

This field is for whoever does the project planning; developers don't really care. It helps record how much we think this work matters to our project's success:

It's used along with "How long will this take" to decide when we're going to work on this task.

What's the bug's state?

This field is used for workflow. Every state shown below is either an "open" or a "closed" state. The bugtracker has shortcuts for showing only open bugs, and that's the main use for this field.

The subdivision into open/closed is the main purpose of this field, however each individual "closed" entry acts to summarise the outcome. This can often be inferred from comments too, but it helps to have a standard place where this information can be found.

There is a bugtracker-enforced rule that a Duplicate bug must have at least one link to say what the bug is a duplicate of.

We're quite explicit about not using an "in progress" state because from past experience, it's very hard to keep this properly up-to-date, and as a result the state can do more harm than good.

What is this bug about?

This is the closest to the conventional "bug type" field. Its main purpose is to describe the entry to a human. We almost never search or filter on this field. It's only there to save words in the bug title. The list varies somewhat from project to project, but here's a representative example:

Empty fields

Picking a value for all of the above is not always easy, so we allow the person entering the bug to leave empty any fields they can't figure out right now. We maintain the attitude that this is perfectly fine, even if you're just feeling lazy, because otherwise we might end up with garbage in these.

The fields "When" and "Importance" are often left blank because these things are for the project planner to decide. Entries with blank "Much work" get reviewed from time to time, with potential assignees asked to estimate it.

Project-specific

While large projects use all of the above, certain small projects do away with fewer. If they have no use for "Importance", we insist that the field is deleted from that project. The idea is that only fields that are being actively used should be present.

P.S. The above screenshots are of YouTrack, which I really rather like. It had no problem with us getting rid of all the built-in fields and using our own.