Issue tracking systems

1 Major issue tracking systems

1.1 Proprietary ones and/or paid services

Will not really cover those, but I never understood what do they take money for, and why would somebody use them. Some of them do not manage to configure mail servers properly, do lack standard features, not really stable, and have terrible UIs; and of course they are not free (as in "makes RMS happy").

1.2 Public services

Such as github, sourceforge, etc. Those are actually handy for hobby and OSS projects, though github will probably look in a decade as sourceforget looks now: those fancy things don't seem to last long, though github has plenty of apparent flaws even now: particularly in UI, and being centralized.

1.3 Trac

Python, 3-clause BSD.

A minimalistic system. Does not support multiple projects nicely (single-project system hacked to host more than one project), perhaps overly minimalistic (features are rather limited), not that easy to deploy properly. Tolerable, perhaps, but poor.

1.4 Bugzilla

Perl, MPL.

Seems to be nice for huge projects, like GNOME, but hard to imagine using it in a relatively small company. User interface is not that handy. Somewhat nice and solid system overall, yet I am just avoiding it.

1.5 Redmine

Ruby, GPL 2.

Plenty of features out of the box, pretty nice overall. Though markup is not good, mail notifications (their headers, in particular) are a bit broken for a long time, and it is rather hard to deploy properly (why don't they provide makefiles or installation scripts? It is not something that is necessarily hard to configure/install), it is one of the best issue trackers.

1.6 Others

There is much more in wiki list and comparison. Most of those are terrible, of course.

2 A better issue tracker

2.1 A saying

There is a saying, that tools should stay out of the way. To ensure that it is there (and that I have phrased it correctly), I have just copied it into a search engine, and found an issue tracking system. Surprisingly, it is not even that far from what I was going to describe, though it is proprietary, and the description just briefly mentions a couple of features.

Anyways, there is that saying. Like with any saying, its interpretations can be controversial; perhaps that's the reason why such a saying can become popular: virtually anyone can agree as long as it is vague enough to fit into one's views. So it might be better to avoid it, and write more precisely.

2.2 Standard protocols for communication

Issue-related (as well as forum) conversations can easily be handled by regular mail in most cases, á la mailing lists, and they should be. Yet, it's usually barely (if at all) working; my perfect issue tracker should use it as its primary communication method, perhaps with various IMs as alternatives.

By the way, once I used to wonder why some people still use mailing lists, while there are fancy web forums. Nowadays those forums are mostly dead, and I don't wonder about that anymore, but others do wonder why some people use mailing lists, while there are fancy web-based issue tracking systems, as can be seen in this HN thread, for instance. I guess it's like that with IRC, too.

2.3 SCM integration

It is common in such systems, though often requires tweaking. So, just decent support with standard features (e.g., closing issues via commit messages).

Though, in addition to that, something like a wiki based on a git (darcs, mercurial, whatever) repository would be nice.

2.4 Installation

Proper installation should not be as painful as it is with the most common issue tracking systems. It is not that easy to perform installation properly on any given system, yet neither it is crazy to assume that there are standard paths, cron, and even systemd around, writing a note for those on less common systems.

2.5 Web interface

It may be useful as an alternative way to communicate, as well as for various overviews, statistics, user settings, and so on; mostly for managers, perhaps, and for tired programmers to skim. Not an essential part, as it usually is.

But it should be usable, too. It may not look like something worthy mentioning, yet some systems don't even provide a way to set a monospaced font, while others have markup-related quirks despite very basic markup.

2.6 Programming languages

Since it can be desirable to extend such systems with plugins, plugins should use something like stdin/stdout + JSON/XML/s-expressions as interface, not language-specific APIs. Though it is not just about issue tracking systems: it is a nice approach in general.

3 A slightly different approach

It might be useful to write a rather general system for message transmission – collecting messages via various pluggable protocols, and redirecting it, according to user-specified rules: e.g., collecting data from mail/XMPP/IRC/issue trackers/repositories, sorting it out, and sending where it should be; routing, sort of.

Reminds me of what bitlbee does, as well as of XMPP and mail transports and some IRC bots, just more general. And that could be a base of a nice issue tracking system, which one can use as a client to other issue trackers, or while others are only using plain mail and repositories.

It is always nice to allow people to use what works best for them individually, without forcing a compromise.

Update: tried something like that, see pipes and communication.

4 Distributed issue trackers

There are less common issue trackers that are distributed, like bugs everywhere. Perhaps worth trying, the description looks nice.