Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We've been dutifully using Trac for several years now, and our "active tickets" list has grown to almost 200 items. These include bugs that are too low priority and too complicated to fix for now, feature requests that have been deferred, issues that have never really generated complaints but everyone agrees ought to be fixed someday, planned code refactorings and other design infelicities that we don't want to lose track of, etc.

As a result, with almost 200 of these issues, the list is almost overwhelming; it's no longer useful as a source of what needs to be worked on right now.

What's the best way to keep track of issues of this sort?

Part of the problem is that some of these issues are such a low priority that they may never get done. I hate to lose track of these items (similar to not wanting to throw something out of my house in case I might need it someday); do I need to throw them out regardless (by marking them as wontfix) and assume I can find them in the future if I ever do need them?

share|improve this question
200 for a whole team made me laugh. :-) I alone have 120 open issues, most of which I'll never come around to fix! -- So to sum up: great question! I was just about to ask the same. – Martin Ba Nov 9 '11 at 16:29
up vote 3 down vote accepted

First have each developer look at each of the items and review/test each item to see if it is still an issue (it may work best to split these up amongst people). Then close any that are no longer an issue or have already been taken care of with other development efforts.

Now make sure that each are marked as either a large, medium, or small development effort. This is a very rough estimate just used to more easily categorize the projects and to help to pull things together. If everything is already estimated then it will help but don't get hung up on the hours. Just go with a quick gut check. It often works to get the develpers in a room and just go through each item and use the effort that the majority of the people feel is appropriate.

Review each of the three effort groups and mark each item in the group with a priority of Critical, High business value, High Technical value, Medium value, Low value, and Never going to fix.

By this point you really know the list inside out and really understand the work that is involved in your backlog and you can start to really make a decision on what to do with the items. Take all the items that are marked as never going to fix and archive them out of your backlog.

Now when you schedule the items to go into your next release you can use the critical and high importance items as the core of your release. Review the list of medium and low priority items and add in any that can be worked on at the same time as the other items in your list because the developers will already be working in that part of the system.

The list of items marked with medium or low prioity can be used as a list of things for people to work on when they have a bit of spare time or as training for new employees. I always find that it is nice to have one person on the team during every itteration working on these items and helping the rest of the team where necessary. This way you are still completing work on the current itterateion but have someone that is flexible and can help put out fires when needed but is handling the issues that wouldn't normally get attention.

One thing that we found was nice was that between each itteration we had a short 2 week period where the entire team would only work on items that were marked with a small development effort. We would focus closing a large number of tickets in a short time.

share|improve this answer

Does Trac have a priority setting? Something like 1 for major show-stoppers and 5 or so for things that would be nice to have done sometime?

If you can sort on priority, you can disregard the lower priority stuff for now.

share|improve this answer
Anything that is on the level of "nice to have done sometime" will never get done. Yank it out. – Aaron McIver Feb 8 '11 at 21:38
@Aaron: I'd rather keep it around in case we want to raise the priority sometime. Clearly, it will never get done at that priority, not unless the developers have far too much time on their hands (and have already made a gopher client for the software and made it haiku-compliant). – David Thornley Feb 8 '11 at 21:49
Trac does have a priority setting, although we've accumulated enough of a backlog that I've just about decided we still need a "yank it out" approach. – Josh Kelley Feb 11 '11 at 2:12


Put them in the attic, wait a year, then move house. That is what I do.

Seriously if you are not going to fix it them forget about it. See Extreme Programming.

But For items about code. You could put them in a code review system, as minor observations. This system can be set up to flag up issues when that part of the system is edited. I found this did not work as co-workers, thought this is what was expected and did not address review observations.

The only way to do it is ruthless prioritisation. Do it now or don't bother.

share|improve this answer

This really depends on a few things.

  1. How large is the team: If the team is large enough you can assign tickets in a fashion that would allow the lower priority items to get completed.
  2. How often do you do releases: If the release cycle is long enough you can get away with adding more things or holding off on a release until you have all the tickets resolved.
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.