During my triages I try to do the following:

1. Resolve duplicate issues.
2. Acknowledge issues that make sense rather leaving them as New.  The basic idea is to have "new" mark issues that are yet to be triaged.
3. Update categories as appropriate.
4. Add relationships if appropriate.
5. If an issue is critical and should be fixed in the next release, then set the target release as appropriate.  I tend not to send everything else for the following release.  I think for an issue to be done, it has to be owned by a dev, important to a release, has a simple patch attached, etc.
6. Whenever an issue is waiting on feedback from reporter make sure it is marked as feedback.  Now the reporter providing feedback will bounce the issue back to new.  Hence, I encourage all developers to use feedback + note, rather than just adding a note when requiring reporter feedback.
7. Add standard tags like "patch" for ones with patches, "plugins", etc.  It may be worth revising a list of such plugins to have us triage in a consistent way.
8. I feel OK resolving as no repro very old bugs assigned to old releases relating to core scenarios.  For example, "unable to attach a file" or "unable to update an issue" on 0.19.0 release for example.
9. If there are very old localization bugs, I expect they would probably be outdated.
10. Our target should always be to resolve more bugs than our incoming rate.  I use the summary page to get stats on this.
11. I resolve support questions in the bug tracker and direct users to the forums for this.  Help with the forums would be greatly appreciate as well.

Hope this helps... of course as we triage we will find some useful refinements or changes to the above.  As usual, feedback is welcome.  I suggest we should even capture our triage process / guidelines on the Wiki.

On Tue, Jan 26, 2010 at 4:21 PM, David Hicks <hickseydr@optusnet.com.au> wrote:
I would have to disagree with automatic closing of issues based on
filter criteria. When I occasionally go through to try and triage some
issues, most of them are valid feature requests. Developers can then
either search for issues related to a topic of interest (custom fields,
attachments, etc) and see the feature requests, or randomly browse
through finding an easy feature to implement.

Bugs should be closed if the reporter was vague, the bug was reported
for a pre 1.2.0 version of Mantis and the chance of receiving extra
useful information on the bug is minimal. Some people just don't know
how to file useful bugs and in those cases, more often than not, it is
"user error" anyway.

I'd be interested in helping triage old bugs too. I think the best way
of doing this would be to sort all our bugs by ID then each person
triaging bugs would take a range of IDs to work on. If there are bugs
which the triager doesn't have a clear idea of whether it is still valid
or not, they can keep a list and post it later for other people to have
a look at.

When triaging we need to look at whether the summary is descriptive,
whether the severity (feature for features, etc) and priority are
correct and whether the category is accurate. So there is a fair bit of
work involved.

Thanks for all the offers of assistance with triaging bugs - it does
make it a lot easier for developers to find the most pressing issues to
work on! And similarly, it makes it easier for users to find issues that
they're facing as well (preventing duplicates, and giving them
workaround solutions).



On Tue, 2010-01-26 at 23:33 +0100, Roland Becker wrote:
> Great to hear that Rolf wants to start with this cleanup.
> I wondered since I started with ManbtisBT (about 2 years ago), how anyone can be able to deal with so much open issues.
> At the moment there are about 2500 issues which are not resolved or closed.
> I think to review and check all of them manually is extremly time consuming.
> For example 10 minutes per issue will result in more than 400 hours of work.
> Just an idea how to get rid of 50% of the work
> Close all issues which match certain criteria, for example:
> All issues which have status "new" but where not changed since 18 months  (about 1000 issues)
> All issues which have status "feedback" but nobody gave feedback for more than six months (about 120 issues)
> Yes, there will be some good and meaningful issues closed, but who will find these in the huge amount of open issues?
> Those people who really are interested will be triggerd by email and can reopen if they want.
> I could also help a little bit to cleanup.
> I am the user atrol in your tracker and the forum, one of the moderators of your forum and contributing in translatewiki to the German translation.
> So if you want, feel free to give me "developer" rights.
> Roland

The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
mantisbt-dev mailing list