Other Distributed Issue Trackers

I looked at a few distributed issue trackers before writing Deft, including:

• TicGit-NG
• Bugs Everywhere
• CiL
• Ditz
• Git-Issues
• DITrack (project seems to be dead)

For my needs, these programs had one or both of the follow limitations:

• Focused more on tracking bugs in existing software than tracking new software. This works fine for open-source software, where the direction of the software is driven by the developers and interested users can report bugs if they find them. It is less useful for commercial software development, where the features and delivery of the software is planned by developers and customers and the customer wants visibility on progress between major milestones.
• Coarse-grained prioritisation, usually bucketing issues by release or milestone. Again, a good fit for open-source projects but awkward for commercial software development methods with short iterations or continual flow, in which releases dates are fixed and release scope varies. Deft maintains a total priority order among features that have the same status, with the top priority issue being at #1, the next priority at #2, and so on. Deft maintains that ordering as the user modifies the feature database and makes it easy to adjust priorities.

Other less important things I wanted:

• Human-readable issue names. Some trackers assign issues unique but cryptic identifiers. This makes it difficult to discuss the contents of the tracker over the phone. Deft uses human-readable names and relies on developers to resolve name clash when merging, or to agree on a naming convention to avoid name clash.
• Issues stored in the same branch as the code. Some trackers store issues in their own branch of the repo. Having issues in the same branch as the code lets me track what the branch is being used for and how it differs from other branches. Since Deft just manipulates files, there's nothing to stop you storing those files in their own branch if you wish, or even outside the code's version control repository altogether.
• Works well with existing (D)VCS tools. The feature database must be easy to deal with when merge conflicts occur. That means plain text or readable structured text, not XML. Deft uses Markdown and YAML.

There are also tools that keep an external issue tracker in sync with a VCS. One example is SCMBug. I prefer to keep all information about a project in a single repository.