I have been trying to follow Joel Spolsky’s advice. Right now it is very hard to say “XULRunner 1.9 needs X hours of work to be ready for production use” because basically nobody (including myself) has any clue what concrete tasks are needed to get from here to there. I have a pretty good mental overview of the tasks, but that is a far cry from “it would take me 412 programming hours to complete them”, and even less the amount of debugging time to get to a final product.
Bugzilla is a pretty good bug tracking tool, but it’s painfully unsuited at task management and software scheduling. Joel recommends a simple spreadsheet, but that has some serious problems when I need to expose the data for lots of people on the web, and probably need to allow multiple programmers to fill in data. Instead of doing nothing, waiting for bugzilla to get better, I have written a little tool to help me manage XULRunner. It uses a custom XML dialect and some XBL magic to create a hierarchical list of tasks, with estimated and actual times for completion, and automatic totals.
Actually, I’m lying. I wrote two different versions of this tool, each with its own problems. I’m posting both URLs for comments and suggestions:
- XUL version that uses server-side persistence – view. This version loads a XUL page directly into memory: the page can be edited inline and saved back to the server using the menu. If this were the final version, I would probably include auto-save functionality and maybe some other stuff. The big advantage of this version is that it persists the open/closed state of each item. The big problem with this version is when two people try to edit simultaneously: there is no collision detection, and there is no real possibility of smart-merge. Currently the “save” functionality is password-protected. If enough people are interested, I’ll make a “playground” version.
- Wiki-based version – view | edit. This version cannot be edited inline: you have to edit the wikimarkup manually… but the markup is pretty readable all on its own, so you don’t even have to use the “view” version if you don’t want to. The big disadvantes of this version are the lack of inline editing, and no persistence of the open-closed state. This version makes use of a special mediawiki patch that allows wiki pages to be viewed “raw” in various mime types, see bug 300657.
Right now, I’m going to use the wiki-based version. In the future I may try again with some special database-oriented system in the future, but this version is “good enough” for my needs; I need to actually work on the data for XULRunner 1.9!
What would be really nice is to make bugzilla less painful to use, and integrate this kind of project-management data into it, but that is a topic for another day.