My Two Cents

Mantis is an efficient bug tracking system probably next only to Bugzilla. But they probably cater to different categories of bug tracking. Whereas Bugzilla suits big projects with numerous users and numerous bugs, Mantis suits smaller projects which does not require the sophistication (and hence the complexity) of Bugzilla.

Being a regular user of Mantis, I have been acutely aware of the lack of an “industry practice” methodology in using the bug tracker. I have made an attempt to explain one such practice on the lifecycle of a bug. There are several other ways to use Mantis including more transition states, but what follows is what I have been using, effectively.

The state transition diagram is self-explanatory. There are four user roles – reporter, manager, developer, tester. Reporter reports an issue. Manager acknowledges the issue and assigns it to a developer, either as a single step, or in two steps. The bug can also be sent back to the reporter either by the manager or developer requesting for feedback. In such a case, the reporter adds the requested explanation. Once the developer resolves the bug (resolve can mean fixing it, marking it as not-fixable, marking it as not-reproducible or any other scenario). Finally, a tester closes the bug if it has indeed been resolved. If the tester finds the bug to be unresolved, it can be sent back to the developer. A bug can be re-opened after it is closed for several reasons such as, the bug being found to be unresolved after being closed, the bug having been closed as suspended (to be fixed later), etc.

There are several other ways to use bugtracker, by changing the state transitions, or by including new states (such as confirmed). They are useful in larger projects with more users involved.