Project management and communication continue to be a personal fascination, and one that I have covered many times in this weblog as I've gone through many tests of assorted bug trackers and document management systems, trying to find "the right one." For the time being, we've settled on Roundup, a standalone bug tracking application written in Python. Roundup is , not terribly difficult to customize, and is fairly flexible. And very fast. The application itself is very agnostic about its storage layer, and in our current setup we're still using basic DBM storage, which was very easy to set up and use. We've made some customizations in our instance (without touching the base code - always a good thing to avoid):
- Simple Document Management: We needed a place to start keeping notes, documentation, tips, memories, requirements, etc. It's not as elegant or nice as a Zope solution might be, but it keeps all of this information in a single place. I added support for docutils and its reStructuredText format, including a directive to refer to other Roundup items (files, issues, projects, etc). It's decent. And I like that everything is kept closely together. But at some point, I really want to start evaluating a more powerful document management system like Silva, primarily to handle large documents such as contracts and proposals as well as all the little remembrance documents.
- Project Management: A project is basically a collection of issues and documents. A project page in our tracker gives a list of all issues and their statuses. The status column on the issue list table is color coded, with lots of green being a good sign the project is finished. Projects follow a simple workflow (new/proposed/in-progress, etc). They've been a nice way for us to have a single tracker instance that encompasses everything in progress. Many Zope based trackers we deployed tended to have a project container with a bug tracker inside of it, which didn't allow for easy sharing (or even moving) of tasks.
Roundup's issue handling is excellent. There are many opinions out there that a weblog is a good place to do project management. This may be true. However, a decent bug tracking system gets you many of the same benefits, but with much more relevant metadata. The important thing one has to do is document their work - how they fixed a bug, how they implemented a feature, etc. A weblog makes good sense for that. But a tracker makes better sense - the conversation is both more open and more focused. Many authors can contribute to the discussion of a particular issue, but the issue (should) remain on the task at hand. To make this communication easy, it's helpful when a Bug Tracker allows mail-in responses to an issue. This way, communication between interested parties remains in the database of the bug tracking system, and not archived off in individual's email folders. When it's two months down the line and someone walks into your office asks "how did we fix that thing with the thing and the stuff?", you can bring the issue back up with a quick search, and hopefully have a good answer, such as, "oh yeah! We converted the value to megabytes at read-time, and rewrite it as bytes at write-time, and the user interface is none-the-wiser."
There is something to be said for the personal journaling experience of weblogs in a project, and this may make sense for some teams. I think it's just important to do the journaling - whether its in a CVS change log, a weblog, or an issue tracker. Or perhaps, a combination of the three. No matter how clever you think you are at solving a problem today, there is always some point in the future where you'll ask yourself "now why did I do it that way?" It's nice to have an answer.