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.)