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

Both sides previous revision Previous revision
Next revision
Previous revision
mantisbt:support_corner [2012/10/04 11:26]
dregad Added sample resolution message for support requests, minor corrections
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.+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. 
 + 
  
  
Line 8: Line 10:
 During triage, try to do the following: During triage, try to do the following:
  
-  - Identify and resolve ​duplicate issues. +  - If possible, try to immediately ​resolve 
-  - Resolve ​support requests (i.e. issues that are neither a bug in Mantis nor a new feature request) as //no change required//​. ​\\ Here is a sample message that can be copy/pasted ​to the closure response <​code>​ +    * duplicates 
-This is not bug or feature request for MantisBT (you are asking for help on how to configure the system). I am therefore resolving this issue as "no change required"​. +    * 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 
-Please use the forums, the mantisbt-help mailing list or IRC to get support ​on customizing and using MantisBT +    * bugs related ​to old releases (see **snippet: Resolve - Old Version**), for example: 
-http://www.mantisbt.org/support.php +      * "​unable to attach ​file" ​or "​unable ​to update an issue" on 0.19.0 release.  
-</​code>​ +      * old localization bugs (prior to swite-TranslateWiki),​ they would probably ​be outdated.
-  ​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.+
   - Update categories as appropriate.   - Update categories as appropriate.
   - Revise priority / severity if needed   - 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 reporterUse 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.+
  
 Help with the forums would be greatly appreciated as well. Help with the forums would be greatly appreciated as well.
 +
  
mantisbt/support_corner.1349364400.txt.gz · Last modified: 2012/10/08 07:08 (external edit)