User Tools

  • Logged in as: anonymous (anonymous)
  • Log Out

Site Tools


mantisbt:support_corner

Differences

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

Link to this comparison view

Next revision
Previous revision
mantisbt:support_corner [2010/01/27 06:02]
rolfkleef created based on Victor's message on the devel list
mantisbt:support_corner [2014/01/09 08:54] (current)
dregad
Line 1: Line 1:
 ====== Support Corner ====== ====== 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 ===== ===== 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.   - Update categories as appropriate.
 +  - Revise priority / severity if needed
   - Add relationships if appropriate.   - 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 bugsthey 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.+
  
mantisbt/support_corner.1264590138.txt.gz · Last modified: 2011/11/16 07:55 (external edit)