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 revisionPrevious revision
Next revision
Previous revision
mantisbt:support_corner [2012/10/04 11:26] – Added sample resolution message for support requests, minor corrections dregadmantisbt: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 "newmark 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 fileor "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)

Driven by DokuWiki