I always have the impression that the bugtracker is a huge mess. So many issues, so many of them unresolved and no idea where to start when trying to solve them. It is so stuffed to the point that I double-think if I really entry another bug with so many other bugs flying around. Of course this is nonsense.

If there is a bug, it must be put into the bugtracker. And if the software is not able to display the bugs in a clear manner, then maybe we should change the software.
But wait, on second thought, is it the software? While searching for other software I noticed that Mantis actually has many features that would enable us to keep better track of the important tickets, we just don't use them.

What is relevant?

I can understand now why many other bugtrackers (namely Bugzilla, The Bug Genie) refuse to show the user a list of open bugs as a welcome on the home page: There might be many tickets, but much less are relevant or urgent. Others shouldn't be forgotten.

So, how can we classify the bugs to have a better overview over where an action is necessary and where not? I have some suggestions:

Use the other bug statuses

Currently we only really use New, Assigned, Resolved. From now on, lets use it more like it was intended by Mantis to have a better classification (Cursive: new statuses).

+ New - All incoming bugs/tickets

+ Feedback - Issues where we are awaiting some reply or additional information from the reporter

+ Acknowleged - Issue can be reproduced/the problem is clarified

+ Confirmed - Issues were enough information is supplied that the (root) problem is clear and that a way how to solve this has been agreed upon, so we can just begin to work on the bug. For feature (requests): Yes, will be done. So these bugs are ready-to-be-solved.

+ Assigned - Assignee is working on it

+ Closed - Issues that are done for good: Resolved for an update that has been released. (The default filter doesn't show these issues)

I already closed all those resolved issues that were fixed prior to the current stable 3.3. So all the resolved and not closed tickets now are either fixed for 4.0 or 3.3. The additional statuses also remove the notion that you have to either take on the issue (or plan to do it) by assigning it to you or don't do anything at all because you don't really understand the problem: The process of finding what the actual problem is is reflected by feedback, acknowledged and confirmed. So you can help to clear up an issue and bring it closer to being resolved.

Importance

Well, first of all there is the Priority field. Can you edit it as a developer?

We need a clear distinction between bugs and {feature requests + personal todos + change requests + performance problems + feature tickets}
Bugs should be trivial, minor, major, crash and block while the second category can be tagged as feature requests or tweaks.

We pretty much do it like this already now, I just wanted to note here that this can be used to filter/order the issues.

Versions and Roadmap

There are three fields that perhaps need an explanation:

+ Version - The openclonk version in which the problem was observed. If you use a development snapshot, don't specify this but note it in the description.

+ Target Version - The openclonk version for which this must be fixed or done. This can be used for feature tickets as well (e.g. "texture the inventor's lab"). Tickets with a target version specified are displayed on the roadmap page.

+ Fixed in - If you resolve a bug, you should specify which is the release version in which the fix will appear. You can leave this empty if this bug wasn't even reported originating from a release version

Opinions?

I added the "Compact" filter in the bug view that hides resolved issues, issues assigned to other people (those tickets shouldn't be assigned for years but only when he is working on it or will be in the next time), hides feature requests and orders by priority.

Do you have any other suggestions how to make the bugtracker more organized, how we could work with it better?