I'm fascinated by our fascination with tools, including bug trackers. Which bug tracker to use and how best to configure it can be a great source of bikeshedding and flamewars. Don't get me wrong; it's important to have good tools. But I think we sometimes overrate the significance of the bug tracker and overlook where it actually sits in the larger picture of how we deal with defects.
Like Krishen Kota points out, a bug tracker is only one part of a defect-management system. It's a tool—one that, amongst other things, is used to implement a process for handling defects. For instance, "testers log bugs; the project manager prioritizes bugs; the development manager assigns bugs to developers to fix" is one simple defect-handling process. In turn, a bug-handling process is informed by the organization's bug management strategy—its plan for which bugs get fixed, when they get fixed, and which (if any) don't.
In my experience, a bug-management strategy is rarely articulated explicitly. More often, it's implicitly communicated by decisions that are made about how individual bugs should be dealt with.
A common strategy is that high-priority or high-severity bugs get dealt with, while low-priority bugs get logged in the bug tracker and deferred indefinitely.
Departing from strategy, Neil Johnson explains that his team has adopted a different strategy—either bugs are important enough to fix immediately, or they're not important enough to deal with at all. On the other hand, Elisabeth Hendrickson argues that fixing some bugs and deferring others based on some notion of ROI is the way to a slow but certain death.
How a software development organization deals with defects says a great deal about its ideals—in particular, its ideas about how software development works and what good software looks like. While the bug-tracking tool is the most visible artifact of how defects are managed, the tool itself—and especially the choice of which exact one to use—is probably not the most significant part of this equation.
