Rules for properly organized bugtracker (Mantis et al)

Question

On a particular project we're working with a total of 10 team members.

After about a year working on the project (and using Mantis as a bug-/feature-tracker eversince), the bugtracker gets more and more difficult to use, as no standard has been setup that explains how to create new tasks, how to comment tasks etc. This leads to multiple entries for the same bugs, inability to easily find bugs when searching for them etc.

How do you organize your bugtracker? Do you use a lot of (sub)categories for different portions of your application (GUI, Backend etc), do you use tags in the title of tasks (i.e. "[GUI][OptionPage] The error")?

Is anyone in your team allowed to introduce new tasks or is this step channeled through a single "Mantis-master" (who would then know whether a new report is a duplicate or an entirely new entry)?

Answer 1

Always link a version control system commit to an issue and back so that you know which commits were made do solve which issue and why a certain commit was done.

Answer 2

What we did is to introduce a role for approve entries to the bug tracker. This role can be shared by different people. The process is either to approve, to approve with a small edit, or to reject the entry with the request for further editing or clarification.

It is better for the general understanding if the role is not given to people working in the (core) team.

Answer 3

In a "large" mantis system on the open web, I've seen the rules go something like

New: Anyone can enter a bug.

Acknowledged: A select few people can upgrade it to this level. These people have seen every new bug for a while, and thus they'll know if it's a duplicate. Or they can pass it back to the reporter for clarification until they understand it well enough to do this job.

Confirmed: Set by decision makers who basically say "We will be doing this".

I don't actually remember where it was, and more importantly I don't know how well it worked.