Bug tracker or trouble ticket system?

One of the issues that comes up from time to time in many organizations and projects (both community and commercial ventures) is the question of how to manage bug reports, feature requests and support requests.

There are a number of open source solutions and proprietary solutions too. I've never seen a proprietary solution that offers any significant benefit over the free and open solutions, so this blog only looks at those that are free and open.

Support request or bug?

One common point of contention is the distinction between support requests and bugs. Users do not always know the difference.

Some systems, like the Github issue tracker, gather all the requests together in a single list. Calling them "Issues" invites people to submit just about anything, such as "I forgot my password".

At the other extreme, some organisations are so keen to keep support requests away from their developers that they operate two systems and a designated support team copies genuine bugs from the customer-facing trouble-ticket/CRM system to the bug tracker. This reduces the amount of spam that hits the development team but there is overhead in running multiple systems and having staff doing cut and paste.

Will people use it?

Another common problem is that a full bug report template is overkill for some issues. If a user is asking for help with some trivial task and if the tool asks them to answer twenty questions about their system, application version, submit log files and other requirements then they won't use it at all and may just revert to sending emails or making phone calls.

Ideally, it should be possible to demand such details only when necessary. For example, if a support engineer routes a request to a queue for developers, then the system may guide the support engineer to make sure the ticket includes attributes that a ticket in the developers' queue should have.

Beyond Perl

Some of the most well known systems in this space are Bugzilla, Request Tracker and OTRS. All of these solutions are developed in Perl.

These days, Python, JavaScript/Node.JS and Java have taken more market share and Perl is chosen less frequently for new projects. Perl skills are declining and younger developers have usually encountered Python as their main scripting language at university.

My personal perspective is that this hinders the ability of Perl projects to attract new blood or leverage the benefits of new Python modules that don't exist in Perl at all.

Bugzilla has fallen out of the Debian and Ubuntu distributions after squeeze due to its complexity. In contrast, Fedora carries the Bugzilla packages and also uses it as their main bug tracker.

Evaluation

I recently started having a look at the range of options in the Wikipedia list of bug tracking systems.

Some of the trends that appear:

  • Many appear to be bug tracking systems rather than issue tracking / general-purpose support systems. How well do they accept non-development issues and keep them from spamming the developers while still providing a useful features for the subset of users who are doing development?
  • A number of them try to bundle other technologies, like wiki or FAQ systems: but how well do they work with existing wikis? This trend towards monolithic products is slightly dangerous. In my own view, a wiki embedded in some other product may not be as well supported as one of the leading purpose-built wikis.
  • Some of them also appear to offer various levels of project management. For development tasks, it is just about essential for dependencies and a roadmap to be tightly integrated with the bug/feature tracker but does it make the system more cumbersome for people dealing with support requests? Many support requests, like "I've lost my password", don't really have any relationship with project management or a project roadmap.
  • Not all appear to handle incoming requests by email. Bug tracking systems can be purely web/form-based, but email is useful for helpdesk systems.

Questions

This leaves me with some of the following questions:

  • Which of these systems can be used as a general purpose help-desk / CRM / trouble-ticket system while also being a full bug and project management tool for developers?
  • For those systems that don't work well for both use cases, which combinations of trouble-ticket system + bug manager are most effective, preferably with some automated integration?
  • Which are more extendable with modern programming practices, such as Python scripting and using Git?
  • Which are more future proof, with choice of database backend, easy upgrades, packages in official distributions like Debian, Ubuntu and Fedora, scalability, IPv6 support?
  • Which of them are suitable for the public internet and which are only considered suitable for private access?

Comments

Take a look at Trac (it's more a bug tracker, but can be used as an issue tracker as well) and email2trac (for ticket creation/update via email). Also interesting (but needs more work) is Odoo (formerly known as OpenERP formerly know as TinyERP), which has both a "helpdesk" and an "project issues" module. Both Trac and Odoo are web-based, written in Python and run e.g. with PostgreSQL as backend and Nginx as frontend. Neither of them use Django or whatever, but build their own framework, database abstraction etc. probably because they are relatively old. Trac is BSD, Odoo is AGPL3. Trac is maybe better for "technical" people, Odoo might attract more the non-technical kind.

I think you shouldn't let your dim view of the future of Perl influence your choice of system too much.

That said, I like Trac. It is simple - which is good, because it makes it possible for most users to reason about what the system will do/just did - while still reasonably featureful. I would always go for simple, and then add the few complicated things you need, rather than the other way around.

It does have a wiki and a repository browser built in - you can just ignore the wiki-part, and the repo browser is actually nice to have, because you can refer to commits in tickets, and refer to/close tickets in commit messages, which will then be linked together.

The greatest drawback with Trac is that it uses an obscure templating language, which makes customization more complicated than necessary.

And some type of customization will almost always be needed.

I use Redmine. It's a general purpose ticket system as well as supporting bug and project management. You can turn off individual features, if you (say) want to use some other wiki software, or prefer only to have bug tracking, or don't want project management.

It runs nicely on PostgreSQL, it's written in Ruby so it's modern and fairly easy to extend, it supports Git repositories with a browsing interface, accepts e-mail tickets, and so on.

Did you see what Lars Wirzenius post recently?
http://blog.liw.fi/posts/on-ticketing-systems/

Better late than never ...

GLPI is a Support Request traker (in PHP, under GPL). It also include some CRM and has plugin to add Gantt graphs and more (many plugins are available). It is missing Git or other VCS integration.

IMHO Mantis (www.mantisbt.org) is a great options. There are several interesting third party plugins (simple SCRUM Board, or complex SCRUM, stats, Email Ticket reporting and more). I've used it since 2003 and I love it!. I use it for issues and for development tasks management