I've been reading Joel on Software and was struck by one of the sections. Bug Databases. Joel explains the minimum you need for a bug database, and the absolute need for one.
I was sitting around the house this Christmas weekend and it occured to me,
"I really should have a bug database. "
So I set to work on bugZ
Following what I have learned from Joel, I started with a simple little spec, outlining what I wanted to accomplish, what was in scope, what was out of scope. After that I went to work. Took me a few hours over Saturday/Sunday and Today.
So I present, bugZ, not to be confused with FogBugz, which bugZ will never be. It's small open source, and likely to only grow as fast as I have free time.
YOu can see some screen shots, here, here and here, and download the SQL code here, and the ColdFusion code here.
I'm calling this V1.0
What it does:
- Allows users to inpout a bug definition (project, phase of project, status, bug description, steps to reproduce, the expected results and the actual results)
- Allows the developer to comment on a bug, and move it to a "fixed" status
- Allows the opener of the bug, or developer to mark a bug as "closed" once the fix has been tested.
What it does not do:
- Email anybody anything at any time
- Allow searches of any type on any topic
- allow users to administer any settings or add new projects to the list
- link to any (or even my) project/ time management application
That not to say future versions won't do these things, in fact I imagine soon this list will be completely gone, but for now, this is what you do and don't get.