Unfeature 4: Custom Fields   by Ryan

We’ve recently been asked what our available ticket statuses mean (and how to change them), and why there aren’t custom fields in the ticket editor.


With each ticket/bug you have a couple goals in mind:

  • Figure out if this is something we need to do.
  • If so, we need to remember that it needs to be done.
  • Keep track of who discovered it and who is supposed to be on it.
  • Log historical records of what happens to it over time.
  • Note how and when it was resolved.

That’s really it. If there’s a due date, you just say so in the ticket. If there’s a screenshot, attach one. But fundamentally these 4 things are what each ticket is really about. And it’s why we only expose the fields we do (if you aren’t familiar they are: title, status, assignee, list, priority, tags and a watch list).

For statuses, we expose the following 4:


It is unknown or undecided what will happen with this ticket. It may not be a bug at all, or it may be a feature proposal or a request to look at an experimental branch, etc. We aren't sure who is necessarily going to take care of it, either. Basically this is an 'incoming' status. Most often, new bugs not yet reproduced/investigated get this status.


Someone is responsible for this. It may still have lots of moving between people to do, it simply shows that the current assignee is the person 'with the ball'. This is, in general, the status during which most of the commenting and discussion takes place.


Someone (probably the person who it was assigned to) thinks this is done and ready to be verified by another team member. It essentially means "ready for testing" and often includes information like commit numbers, links to staging servers, etc.


This ticket has been resolved. It will have been given a closure 'reason', one of:

  • verified – It is indeed fixed. High fives all around.
  • invalid – This is not a bug, or won't be fixed/changed for whatever reason (usually the closer will comment as to why).
  • intentional – This behaves as expected/intended/designed and there is nothing to be done.
  • duplicate – This is logged/discussed somewhere else (again usually accompanied by a comment telling you where).


It might seem like having tons of checkboxes, dials and controls would be a good thing – “I can sort by due-date!” or “Show me all the tickets affecting Windows XP!” – but this sort of fine-grained information gathering is just wasting people’s time and makes using the UI an unpleasant experience.

The downside is that you can’t sort tickets by arbitrary things like “frequency” or “url”. If your app is very tightly coupled to something in a way that every single ticket must have field X filled out, you’ll miss it. In cases like that we think just standardizing within your team on something like using the titles of tickets – “[IE8] Like this” – makes sense, but there are plenty of other approaches as well (try using tags!).


The fact is that for most use cases you just don’t need elaborate fine-grained fields for every single detail. Bonus tidbit: If you use the title, tags or the first comment for stuff like this it will get indexed for full-text searching.

At the end of the day Bugrocket is about making a small light-weight application that involves as little clicking of widgets and typing into textareas and inputs as possible. As developers ourselves it’s the thing we appreciate most about using Bugrocket every day.