Ten best practices for scientific software development.
Using issue tracking software to track issues, bugs, and features creates a centralized, external task list that facilitates collaboration, transparency, and accountability.
Ever heard of "feature creep"? Anyone developing scientific software for any amount of time will know what it means. It's also a common phrase in the software industry. Feature creep comes about as a result of the human condition, and how easy it is to create a wish list of things you wished the software had, as opposed to truly appreciating the features that the software already has. It's easy for that wish list to quickly grow out of hand, and become a laundry list. This can instantly turn a task list to spaghetti.
At first glance, it may seem impossible to head off this problem. But there is a solution - issue tracking software. Issue tracking software can force the software's users to be thoughtful about the features that have the highest priority, and to articulate those features they deem the most important. It provides a record of what features and problems developers are spending time on. And it provides a system by which the features and issues the devlopers are working are organized - by category, by importance, or by priority.
Issue tracking is more than simply a list of issues and features maintained by developers. A good issue tracking system is accessible by both the developers and the users of the software. There should be a system for "tagging" issues and bugs to classify what part of the code they affect. Some thought up front should be put in to these tags for features and bugs.
However, the issue tracking system should also be flexible enough that if code development takes a different turn, the existing sytem can be adapted, and need not be scrapped. Flexibility is key.
Most issue tracking software will use a web interface hooked up to a backend database, since a web interface minimizes the amount of specialized training that's needed to use it (thus making it easily accessible to users).
This is, almost without exception, the model that most issue tracking software will use.
It may be possible to use a Help Desk style ticket system, but be wary of solutions like this - these tend to avoid the benefits of issue tracking software (the documentation, public accessibility, and record-keeping of an issue tracking software) and will usually contribute to, rather than prevent, feature creep.
There are multiple options for issue tracking software. One older software that is still very popular is called Bugzilla. Bugzilla is a web-based bug tracking software, with multiple features including versioning, tags, email integration, and issue assignment.
Another option for issue tracking software is to utilize a software package like RedMine or Trac, which can provide multiple solutions in one integrated package (wiki, mailing lists, version control, and issue tracking software). We will see these options again later.
The third option, which is becoming more popular due to its ubiquity and ease of use, is to leverage GitHub's free, integrated issue tracking feature built into every GitHub repository. This is nice because of the fact that, once you become fluent with GitHub's issue tracking system, it will translate to thousands of other open-source projects all using the same issue tracking system.
You can also check out this Wikipedia article listing dozens of issue tracking software options, along with the licenses they use, the features they offer, and their age.
My recommendation, if you aren't sure which route to take, is to utilize GitHub - if for no other reason than its popularity/ubiquity.