Decentralized Issue Tracking

De-Facto standard in modern software development for version control is git. Git is awesome, works really well and can be applied to a varity of workflows. With git, one can use E-Mail lists as decentralized communication.

What git lacks is a distributed issue tracker.

In the following I use “DIT” for “Distributed Issue Tracker/Tracking” or “Decentralized Issue Tracker/Tracking”

Problems with distributed issue tracking

Some basic things which you want to do with decentralized issue tracking is using plaintext as data format. Using anything else is just insane, if you think of git as a plain-text version control system (in “we version-control text, not binary data”).

Secondly, you want your issues be right in your git repository, as issues are always related to code in our world.

Sync

One big problem is of course the synchonization of the content. With git, you do synchronization on a pull-request basis, but you don't want that for a issue tracking system, do you?

One would have to approve issues before they are propagated to the community of a project, which is complicated. One could use the E-Mail workflow which was introduced with git, git send-email and git format-patch, though most users do not even use these functionalities of git.

Comments

Of course issues include discussions which contain commits of up to N people. An DIT must be able to not only synchronize them but also print them in a sane way.

Status

Most issue trackers allow things like tagging, setting a status for an issue, assign issues to contributors of the project and so on. How would one model these things?

Data format

Of course, one would implement such a system for doing issue tracking in plain text (besides the points noted in “Binary Data” below). But how would one organize the comments, tags, status updates, labels, assignees, etc. etc.

One would need to define an both easy and powerful plain text data format for this.

Where to keep the content

Do you want to keep the issue content in the source code repository of your project? Do you want to use another subdirectory inside your repository just for issue tracking? Or should one store this content within the .git directory somehow (like git-annex does)?

Or do you want to have a dedicated repository for issue tracking, increasing the complexity of referencing from one repository to another?

Binary data

Sometimes it makes sense to check-in binary data with issues, such as generated PDF files (imagine a tex project where the output looks not nice and you want to file a proof of concept for a new design of the document), images (think of screenshots) or other debugging data (core dumps, large log files, sqlite databases or things like that).

References

When writing a comment in an issue, you might want to reference other comments or code lines. An DIT must have an ability to handle references and to display them in a sane format.

Authentication

How to authenticate someone so she is allowed to add issues to the issue tracking system if you have a distributed system without a central component which does the authentication for you?

One could solve this issue by using the E-Mail patch workflow support which is baked into git, but then you again have the problem that someone has to approve issues. For a large system, this might make sense, for smaller systems it is just hassle you don't want to have. Also this requires knowledge about git send-email most users of git don't have these days.

Workflow support

Of course, a wide range of workflows has to be supported by the system. I don't even know about different workflows for issue tracking, so I cannot write a lot about problems which might come up with a distributed issue tracker.

Integration into existing systems

To establish such a system, integration with existing platforms is desired. Integrating github issues, redmine, gitlab, gogs and all the other (centralized) platforms out there.

And, almost more important, two-way-synchronization is desired. If one files an issue on github, the DIT must get this issue somehow and it must be further distributed into the issue trackers of the other systems, including comments, status updates, labels, etc. etc.

Wiki software

Some issue trackers include a wiki software. It is not required for issue tracking, but would be a nice-to-have for an issue tracker IMHO.

Interface(s)

Another problem is the interface such an issue tracker has to provide. Of course, some users want the commandline as interface, but others want a nice and fancy-looking web-gui, graphical interfaces or some might want to have a email-based interface.

The commandline would be the core of the system, of course. A DIT which is supposed to use git or integrate well with git must implement a commandline interface, no question.

Lesser complicated Problems

Lesser complicated problems include full-text search, tool integration (writing plugins for vim, emacs and other lesser cool editors and IDEs won't be a problem after a good DIT system exists), GUI or web interfaces, ...

Existing systems and their problems

Some approaches on this problem exist, though all of them are unmaintained and stalled.

More resources

There are some more resources on the problem, including a blog post on the “Current State of distributed issue tracking” (2010).

The wikipedia site on distributed issue tracking lists some software solutions, including gitit (wikipedia) and ikiwiki (wikipedia).

Brain-Dump of ideas

Of course, listing problems is nice though might not result in progress or even ideas. Here go some ideas I have.

First of all I though one should implement such a system from scratch. While this seems to be the most flexible solution in terms of implementation details, it might double efforts.

My current thoughts are that one should re-use the codebase of bugseverywhere (or one of the other solutions) learn from it and start rewriting and going on from a certain point of the solution to solve the remaining issues. Using ikiwiki as distributed issue tracker (as listed by wikipedia) could be a nice idea.

One crucial point for me is that this kind of software should not be implemented in, for example, Ruby. One should implement such a software in python (despite the pain), bash or a similiar wide-spread language. Of course, implementing it in a language which is compiled to a binary would be nice as well (Thinking of either Rust or C++ here, not necessarily Haskell). Scripting would be faster progress and if the system is well-defined one could rewrite parts of it in other languages later on, of course.

Just my two-cents.

tags: #git #software #tools