Differences

This shows you the differences between two versions of the page.

--- mantisbt:support_corner [2011/11/16 07:55] – The page rendering was broken (maybe since new PHP version on mantisbt.org). Added new line to fix it at end of file. atrol
+++ mantisbt:support_corner [2014/01/09 08:54] (current) – dregad
@@ Line 1: / Line 1: @@
 ====== Support Corner ======
+Our target should always be to resolve more bugs than our incoming rate. Use the [[http://www.mantisbt.org/bugs/summary_page.php|summary page]] to get stats on this.
 ===== Triage process =====
-During triages, try to do the following:
+During triage, try to do the following:
-  - Resolve duplicate issues.
+  - If possible, try to immediately resolve
-  - 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.
+    * duplicates
+    * 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.
-  - If an issue is critical and should be fixed in the next release, then set the target release as appropriate.  Do not send everything else 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.
+  - 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.
-  - 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, developers should use feedback + note, rather than just adding a note when requiring reporter feedback.
+  - 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.
-  - 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.
+  - 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.
-  - It is OK resolving as "unable to reproduce" 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.
+  - 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.
-  - If there are very old localization bugs, they would probably be outdated.
-  - Our target should always be to resolve more bugs than our incoming rate.  Use the summary page to get stats on this.
+Help with the forums would be greatly appreciated as well.
-  - 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.