So far in my life I have used and tried five different bugtracking systems: Bugzilla, Mantis, Zope orgs "Collector", one I wrote myself in Lotus Notes ten years ago, and now lately Trac.
Trac is cool, because it has a Wiki. Other than that, these systems are pretty much all crap, although Trac is quite likely less crap than the others. So this blog started as a complaint over the bad state of bug trackers...
...but, it quickly turned into something less whiney and more constructive; a feature requirement list of bug tracking systems. This are some features I can come up with that I want in a bug tracker. You are welcome to add your own requirements as comments, and if I get a lot of comments, I'll merge this into another blog entry later.
You are also welcome to come with more recommendations of bug trackers. I don't have time to test bug trackers in detail, so if you say bug tracker X has feature Y, I will just believe you. Hype your own product!
1. Workflow
You need to be able to assign tickets to different persons, add comments, reassign and move around, and of course, see what is assigned to you.
2. Flexible schema
Every company/open source community has it's own requirements of what the bug report should include. Lets see some examples of this:
Organizing Projects/Products/Modules/Components.
A company that makes commercial products might want to have products that consist of several component products. For example, Norton SystemWorks include Norton AntiVirus, and Norton DiskDoctor and so on.
Consulting companies need projects that are orthogonal to components.
Therefore there need to be some sort of top-level attribute to each bugreport/ticket (different names, same thing) that selects this product/project, and there must be an attribute to select the component, and these should be orthogonal. A component that is used in several projects/products should not need redefinition in each project/product.
Also, this top level attribute needs to be renamable between project and product (and maybe something else).
Extra candy would be nice an ability to select which modules are used in a project, and a non-orthogonal component collections, or even a component hierarchy. If you have collections of components, these might be called "products", but then again, if your other top hierarchy is "products", they should not. So yet again, the name needs to be configurable. And so should the name "modules" too.
Lets see how the products I tried fulfull this:
Mozilla: Yes! Has a product and a component. These are orthogonal. There is no easy renaming that I know of, but I guess you can change the HTML-forms in worst case. There is no selection of which components are valid for which products, as far as I can see. No non-orthogonal component collections, either, so non of the nice extras are there.
Mantis: No. Has projects and categories but these are not orthogonal. Projects are the all-encompassing major division, and everything else is unique to that project.
Trac: No. Has only components.
Version numbers
Any bug report needs to have a version number field. In a big company, it should be a requiered drop-down box, to make it easier for support to know if this is a known/solved bug that just got reported again. But the numbers in this drop-down box needs to be maintained, and they need to be unique to each product. We all know a small company is not gonna maintain those lists, so it should also be possible to just have a text-field.Again we see that some configurability here is needed.
Status
What the possible status of a bug report should be causes a lot of discussion when it comes to Zope.orgs collector. This is clearly a matter of different needs. Should the reason for closing be a status or a separate field? depends on what reasons you want to allow, and so on.
I'm sure I could come up with more examples of how the schema needs differs if I want to, but this should be enough.
3. Project management
a. Milestones
Each bug report should be able to be assigned a target milestone and a blocker status (only by the project managers of course). You should be able to get a list of what bugs are blocking, and who the guy is that is supposed to fix it.
Mozilla: Yes!
Mantis: No.
Trac: Yes!
b. XP support
Each bugreport should also be an XP card, and it should be possible to do all the things you do with XP cards, i e set a projected time for how long it probably will take to fix it, as well as set in the actual number of hours it took to fix it when it was fixed. Of course, with the simple addition (whic most bugtrackers already have) to mark something as a feature request, and not a bug, this turns the bugtracker into an XP-project management software.
I know of no software that supports this.
4. Security
The ability to assign different people different security depending on
what product/project you are on, and also restricting access to bug reports
considering security is a requirement.
5. Good queries with simple access
If you look at one bug ticket, and you want to see the rest for one component, all you should need to do is click the component name. Going to the query page and making a query each time is way to many steps.(Post originally written by Lennart Regebro on the old Nuxeo blogs.)
Comments