I've looked at a lot of bug trackers over the years, and I even had a crack at writing my own as part of my final year university project. It was certainly an experience, and it taught me the value of "eating your own dog food".
There are hundreds of bug trackers in the wild, and they range in quality and functionality. Some are in-depth packages that really ease the process and were clearly designed with developers in mind. Others are not so good.
With so much choice available, it's good to look at the pros and cons of various systems. It's also important to make a list of your requirements, and as indies we often have a different set of criteria from larger companies.
There are plenty of reasons to use a dedicated issue tracker:
- Organisation – Problems with the software are recorded in a central place, so you don't have to worry about losing that post-it note with an issue's details scrawled on it.
- Transparency – Although it can seem counter-intuitive, letting your potential customers see your bug database can have a positive effect because it lets them see that you're actively fixing problems. It also lets them know that there's a place they can send problems, and that they'll be dealt with efficiently and not swept under the rug.
- Distributed Teams – If there are several developers involved with a project, having a central system where tasks are assigned is a Good Thing. It saves multiple people solving the same problem, and helps to share the workload.
- Documenting the Process – You know what was fixed, when it was fixed and who fixed it. In some systems, you can also find out where the problem occurred in the source code and use this information to improve the quality of code.
- Feedback and Support – Some systems also allow users to submit feature requests as well as support queries. Again, this helps with keeping things organised and preventing things from getting lost.
Everyone has their own set of requirements, but as a general rule indie developers will not have the same requirements as a larger company. For a start, we'll want it to be as cheap as possible! Thankfully there are a lot of open-source projects available that will run on most web servers.
I've put together my own list of requirements for an issue tracker. They're by no means a definitive list, but they're a good starting point for your own list.
- Easy to Use – Not everyone is technically minded, and I want the system to be accessible by as many people as possible.
- Support for Multiple Projects – I want something that can manage several projects, as it will be a central place for all my work.
- Access Levels For Projects, Issues And Fields – Although transparency is good, I still want a certain level of privacy with issues. The ability to set projects as private is important, as they might be WIP or not ready to be announced.
- Anonymous Viewing – I don't want people to have to register just to view the list of bugs.
- Templates – I'd like the bug database to fit in with the rest of the site. If templates aren't available, it should at least have a clean interface.
- Web Service API – An API is nice so that applications can submit their bug reports. This can be kludged if not available, but it's nice if it's built in.
- Project Overviews – I'd like to see overviews of projects, either with graphs or just a configurable list.
- Subversion Integration – As mentioned in my previous post, I use Subversion to track changes in my projects. I'd like a bug tracker that integrates with SVN so I can see what files were changed to fix an issue.
Here are some of the better solutions I've looked at. I can't really do them justice in a few paragraphs, and most issue trackers have the same core features so I've tried to pick out some of their more interesting aspects.
Eventum is an issue tracker from the MySQL team. Features include support for multiple projects, web-based and command line interfaces, and full CVS integration (Subversion integration is available at the Eventum Wiki). It also features XML-RPC and SOAP web services, as well as an IRC Bot which looks useful for distributed teams.
Mantis is an open-source, PHP/MySQL based bug tracker. It's simple and lightweight, but is designed to be easily extendable for people who want a little bit more. If you're not after anything complex, Mantis is a good place to start.
A very slick looking, open-source issue tracker. It supports attachments for issues, as well as multiple products, editions and milestones. You can also set it up to email you whenever an issue is posted. It's very customisable, and you can alter the built in help as well as alter the appearance using themes.
A feature packed, highly extendable piece of kit. The search features in particular are worth noting, as searches can be saved, shared and subscribed to. It can be extended to integrate with source control, and it features XML-RPC, SOAP and REST web service interfaces.
A comprehensive bug tracker, tailored toward making the workflow as smooth as possible. Issues are always assigned to a single person, and this person becomes responsible for fixing the problem (or delegating it). The interface is very clean and clearly tailored towards ease of use.
One particularly nice feature is its ability to add customer emails directly to the system. For example, a customer email to "firstname.lastname@example.org" can be automatically entered into the system and become a new case. This case can then be assigned appropriately. The customer also receives an email with their case number, allowing them to see exactly what's going on.
OnTime features a web-based interface, as well as Windows and Visual Studio clients. It can be integrated with several source control systems, including Subversion and Perforce. You can also define and use your own workflow, such as XP or Scrum.
Most of the issue trackers listed have demos that you can play around with to get a feel for the software, and I recommend trying a few out before settling down. I've tried several of the ones listed, and I've still found it hard to pick one. Although any system is better than none, it's still important to choose one that "feels" right.
I'm always interested to see what other developers use for issue tracking, whether it's a pen and paper, an Access database or something more complex. Feel free to let me know what you're using, and why.