Using Mantis Bug Tracker

Overview
This document describes a proposed new bug tracking system for XXXXXXXX, built using Mantis Bug Tracker, a php/MySQL/web based bugtracking system. The main website is <http://www.mantisbt.org/>, the forums are at <http://forums.mantisbt.org/>, the Mantis bug database is at <http://bugs.mantisbt.org/> (hosted using Mantis; sign in anonymously, or create your own account), and the Mantis manual is at <http://manual.mantisbt.org>.

I've installed Mantis 1.0.0rc2 on the XXXXXXXX development web site. I've customized it to [what I think are] our needs, and created accounts for each member of the XXXXXXXX team. To see the installation, go to http://XXXXXXXXXXXX and click on "Mantis Bug Tracker (demo)". The development website is protected so when queried you'll need to enter "XXXXXXXX"/"XXXXXXXX".

The system requires that you login to view/add/modify bugs. I've set up four test accounts with the four different possible access levels:

• "testviewer" - can only view bug reports
• "testreporter" - can view and add bug reports
• "testdeveloper" - can view, add, modify and handle bug reports
• "testadministrator" - can do anything

These all have empty passwords at the moment. The more powerful accounts are more complicated to use; the simpler accounts are less flexible.

In addition, I've set up personal accounts for everyone, again with empty passwords: usernames "XXXXXX", "XXXXXX", "XXXXXX", "XXXXXX", "XXXXXX", "XXXXXX" and "XXXXXX". All have access level "developer" except for "XXXXXX", "XXXXXX" and "XXXXXX", which have access level "administrator". (If you want your access level changed up or down I would be happy to comply.)

Issue life cycle
Most issues go through a series of states, as denoted by their status: "new", "assigned", "resolved" and then "closed". "New" means the issue has just been created and isn't being handled by anyone. "Assigned" means the issue is being handled by someone, who is responsible for shepherding the issue on (generally this is the person who will consider doing the requested change). "Resolved" means that the issue has provisionally been handled. "Closed" means that the issue has definitively been handled. "feedback" status is used when an issue doesn't follow the standard path (e.g. a bug that has been closed must be reopened); as necessary, the issue can then be moved from "feedback" to "assigned", "resolved" or "closed.

At the beginning of an issue's life, a reporter creates the new issue, entering title, category, reproducibility, severity, priority (if permissions allow), summary, description, and additional information, and attaching any related documents. The issue will have the status "new" until it is assigned to a developer to be handled. This can happen manually (by whomever reviews new issues) or automatically (by specifying a category which specifies a default developer).

When an issue is assigned to a developer, the developer will be notified via email. The developer then reviews the issue, exploring how to resolve it. During this time developers can add notes, change the various issue properties, add attachments, or assign it to another developer.

Once the assigned developer feels the issue has been addressed, he will set its Resolution field appropriately and change its status to "resolved". The issue will then be reviewed to make sure it has been correctly resolved, and if so will be changed to "closed".

Sometimes an issue needs to be taken off of the new/assigned/resolved/closed track, which requires the "feedback" status. A "resolved" or "closed" defect issue, with resolution "fixed", may turn out not to have been fixed; the issue is then put into "feedback" status with a note explaining why, and should then be reassigned to a developer. A "resolved" or "closed" feature issue, with resolution "will not fix", may be found to be a valuable enhancement; the issue is again put into "feedback" status with a note explaining why, and should then be reassigned to a developer.

Glossary

This section goes over the various terms used in this installation of Mantis, along with possible values if relevant.

Access Level

A user property, controlling what the user is allowed to view and modify, as well as the complexity of the interface. The access levels are:

• viewer: allowed to view but not modify issues
• reporter: same as viewer, except can create new issues
• developer: same as reporter, except can modify issues
• administrator: same as developer, except can reconfigure the issue tracker.

[Note that in the default Mantis installation, there are two more access levels: manager and updater. For our purposes I decided to remove these levels in order to simplify the process.]

Category

An issue property, giving the aspect of the product involved in the issue. Specified by the reporter that created the issue, but may be changed later. Category names should fit into the sentence "This issue pertains to the XXXXXXXX of this project." A category can optionally specify a default developer; all new issues with that cagegory will be automatically assigned to that developer. Possible values are:

• Audio system
• Cables and connectors
• Configuration
• Design
• Development tools
• Documentation
• Front panel
• GPIO interface
• Images
• Installer
• Memory
• Motherboard
• Networking
• Other
• Power
• Rear panel
• Security
• Serial interface
• Text
• Web interface

Issue

A single report in the database

Priority

An issue property, giving the importance of addressing the issue. Specified by the reporter that created the issue, but may be changed later. Possible values are:

• None
• Low
• Normal
• High
• Urgent
• Immediate

Project

A collection of issues involving a single major area of XXXXXXXX's products. Reporters choose a project for each reported issue, although issues may be moved later. Possible values are:

• XXXXXXXX
• XXXXXXXX (with subprojects:
  • XXXXXXXX
  • XXXXXXXX
  • XXXXXXXX
  • XXXXXXXX)
• XXXXXXXX

Reproducibility

An issue property, giving how often the issue has been seen when trying to reproduce it. Specified by the reporter that created the issue, but may be changed later. Possible values are:

• always
• sometimes
• rarely
• not seen again
• have not tried
• N/A

[Note that the default Mantis strings are always, sometimes, random, have not tried, unable to reproduce, N/A. I've regularized them so that they all could fit into the same statement about reproducibility.]

Resolution

An issue property, set by the developer when reviewing the issue. Gives how the issue was fixed, or if not fixed describes why. Some values of resolution are only allowed if the issue status is resolved or closed; these are marked with "*" below. Note that here, to "fix" a defect issue means repair it, but to "fix" a feature request means implement it. Possible values are:

• open
• fixed
• reopened (issue Status had been resolved or closed, but is now being reevaluated)
• duplicate*
• works for me: developer couldn't duplicate reported defect*
• not a problem: product is best without issue being fixed*
• deferred: will not fix now, but may reevaluate later*
• won't fix: will not fix for other reasons (e.g. too much work compared to benefit, would cause other problems)

[Note that the default Mantis installation has another resolution, "Not Fixable". In addition, I renamed "suspended" to "deferred", which seems clearer.]

Severity

An issue property, answering the question "when the problem occurs, how bad are the effects?" Specified by the reporter that created the issue, but may be changed later. Possible values are:

• Feature: issue does not describe a problem
• Typo: text is incorrect
• Trivial: extremely minor issue
• Minor: not trivial, but there is a workaround
• Major: there is no workaround
• Crash: product crashes
• Block: prevents operating or testing part of system

[Note that I removed the default Mantis severity "Tweak", since it seemed too close to "Trivial". I also renamed "Text" to "Typo", since the latter seems clearer.]

Status

An issue property, giving the (wait for it!) status of the issue. Possible values are:

• new: issue has not been acted upon or assigned to a developer
• assigned: issue is being acted upon by a developer
• resolved: issue has been provisionally handled, resolution field must be set
• closed: issue has been definitively handled; should not edit issue without reopening; Resolution field must be set
• feedback: catch-all disruption in the issue life-cycle

[Note that the default Mantis installation has two additional statuses; acknowledged and confirmed. I removed them for simplicity's sake.]

Notes

Envelope-to: griscom@suitable.com
To: griscom@suitable.com
Subject: [Audio Time Manager 0000009]: Test issue in ATM
Date: Fri, 16 Sep 2005 12:37:51 -0400
From: griscom@suitable.com


The following issue has been ASSIGNED.
======================================================================
...

then let me know and I'll do something about it.