02-06-2012, 04:24 PM
Documentation for Mantis Bug Tracking Tool
Documentation for Mantis Bug Tracking Tool.docx (Size: 34.39 KB / Downloads: 42)
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.
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.
• Updater:
• Manager:
• 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
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
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.]