Issue tracking systems

Major issue tracking systems

Proprietary ones and/or paid services

Will not cover those, it's mainly a source of frustration to me: they tend to be all broken (perhaps not even worth listing: virtually everything that can be broken is broken at least in some of those) with no hope for improvement, yet managing to get sold and used in companies. I can go on complaining, but it won't be of much use.

Public services

Such as GitHub, SourceForge, Bitbucket, etc. Those are actually handy for hobby 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. Still, GitHub is used by plenty of rather large and nice projects as their primary BTS (and hosting, too).

Trac

Python, 3-clause BSD. A somewhat minimalistic system. Does not support multiple projects nicely (single-project system hacked to host more than one project), features are rather limited, not that easy to deploy properly. Though deemed good enough (and used) for large projects such as GHC.

Bugzilla

Perl, MPL. Seems to be nice for huge projects such as GNOME, but perhaps not so nice for using in a relatively small company (or small hobby projects). User interface is not that handy. Somewhat nice and solid system overall, yet I am just avoiding it.

Redmine

Ruby, GPLv2. 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.

roundup

Python, MIT. Supports email seemingly well, the web interface is quite clean and simple, JS-free, has fine documentation, relatively easy to install nicely. Though apparently the documentation is outdated: pointing out that it is in Debian repositories, while it is not anymore (well, it is in oldstable), and the last release at the time of writing (2017-11-30) is almost two years old. Hence no automated security updates and awkward manual installation; risky to deploy overall.

debbugs

Mostly Perl, GPLv2. Very lightweight web UI, mail-only updates, actively used and maintained for 23 years now. Same issues as with most of the BTSes though: not in repositories, rather cumbersome manual installation, configuration, and maintenance. debbugs git repository is perhaps the primary source for its documentation (and sources).

Others

There is much more in the Wikipedia Comparison of issue-tracking systems and Comparison of project management software. Most of those are pretty bad.

Common issues

• Installation, configuration, maintenance: for some reason issue tracking systems are among the worst kinds of software in that.
• Flexibility and accessibility versus shiny things: as with other communication-related software, some want the UIs they can configure and improve (e.g., email interfaces, FLOSS), and others want them to be all shiny (e.g., fancy visual effects and pictures, often JS-based; possibly integrations with smartphone things and other trendy stuff); those two rarely fit together. There's no fundamental reason why such software can't have multiple UIs, but usually it doesn't, which is pretty unfortunate.
• Extensibility: this may be unnecessary, and often gets awkward, but in some cases it is handy if a BTS can be extended to assist particular workflows. Language-agnostic extension mechanisms are uncommon.

Other approaches

Retrieval and routing

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.

Distributed issue trackers

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