Skip to main content

Bug tracking

July 26, 2010 Author: Joan StarrCategories: Tags:

I’m managing a project that recently launched an early limited release, and one of our next tasks was to select a bug tracking tool. It would help us manage tasks going forward. We had some choices because my organization doesn’t have a standard. Teams can adopt their own methodology, and we encourage adherence to a set of guidelines we developed for selecting collaboration tools.

In practice, like any other organization, we have limited bandwidth for puttering with tools, so teams tend to piggyback on the experimentation of others. Two tools for bug tracking are currently used most widely: Trac and RedMine. So naturally my project team looked most closely at these. They are both free open-source solutions that have been stable for about 4 years.

Image courtesy of San Diego State University; © 2009 Lee Passmore Family http://content.cdlib.org/ark:/13030/kt7w1038cs/?query=Insect&brand=calisphere

There are, of course, many other bug tracking solutions. There are even many other free open source bug tracking solutions. Bug tracking is the kind of itch that lots of people think they can scratch better than the next guy. The kinds of features that developers and managers find especially helpful include:

  • email integration–so that people don’t have to go to the tracker unless it’s absolutely necessary.
  • access control–the more nuanced the permission structure, the better.
  • custom fields–the opportunity to make the tool conform to your organization’s use, and not the other way around.
  • reports–what some people call “dynamic documentation.” Also important is the ability to sort by custom fields.
  • customizable workflows–fancier tools allow for ticket routing choices, reminders, escalations, and vacation or time-away re-routing.
  • integration with the version control system of choice.

Other considerations might be internationalization (Unicode support), the difference between a hosted or installed solution, and what costs might masked by the label “free open source” tool. That is to say, when is free not so free? I recall Karen Schneider highlighting that question a few years ago at Code4Lib by putting up a slide showing free cats vs. free beer. (I see she’s been talking about it again more recently.)

A final factor may have more influence than many of the others, and that is the weight of inertia: the sheer reluctance to allocate precious project time to converting from one tool to another. Even though there are often automated ways to migrate tickets from some systems to another, many of us dislike this process.

So, I was surprised by the response I got at a recent demo of RedMine to a group of Trac users. The main thrust was that RedMine did everything Trac did, and then some. They liked the Gantt chart and calendar views that come with RedMine, for example. And, we are in the process of adopting Mercurial source control management software as a standard tool, and RedMine has native support for this, whereas Trac support requires a plug-in.

The bottom line is that it looks like some Trac-to-RedMine conversions are in the offing, and my team is adopting RedMine. Perhaps we will move toward a defacto standard after all!