Our target should always be to resolve more bugs than our incoming rate. Use the summary page to get stats on this.
During triage, try to do the following:
- If possible, try to immediately resolve
- support requests (i.e. issues that are neither a bug in Mantis nor a new feature request) as no change required. Use of the predefined snippet: Resolve - No Bug/Feature is recommended
- bugs related to old releases (see snippet: Resolve - Old Version), for example:
- “unable to attach a file” or “unable to update an issue” on 0.19.0 release.
- old localization bugs (prior to swite-TranslateWiki), they would probably be outdated.
- Update categories as appropriate.
- Revise priority / severity if needed
- Add relationships if appropriate.
- Set target release: If an issue is critical and should be fixed quickly, then set the target release as appropriate. Do not assign all issues for the following release. For an issue to be done, it has to be owned by a developer, important to a release, has a simple patch attached, etc.
- Add standard tags like “patch” for ones with patches, “plugins”, etc.
Note: It may be worth revising a list of such tags to have us triage in a consistent way.
- 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.
- Whenever requesting additional information from the reporter, Use of one of the MoreInfo* snippets in the feedback request bugnote is recommended.
Also make sure that the status is changed to feedback, so that the reporter knows that their input is required; the next note they add will automatically bounce the issue's status back to new.
Help with the forums would be greatly appreciated as well.
mantisbt/support_corner.txt · Last modified: 2014/01/09 08:54 by dregad