Confirmed users
5,365
edits
Support/How SUMO uses bugzilla with Lithium: Difference between revisions
Support/How SUMO uses bugzilla with Lithium (view source)
Revision as of 16:26, 1 June 2017
, 1 June 2017→Followup at the beginning of every marketing sprint: link to sprint dates
(→Life Cycle of a SUMO Lithium bug: severity enhancement, 100 bugs) |
(→Followup at the beginning of every marketing sprint: link to sprint dates) |
||
| (5 intermediate revisions by the same user not shown) | |||
| Line 7: | Line 7: | ||
= Life Cycle of a SUMO Lithium bug = | = Life Cycle of a SUMO Lithium bug = | ||
* A bug is created in the support.mozilla.org (Lithium) product | * A bug is created in the support.mozilla.org (Lithium) product | ||
* Within 2 business days, [[ | * Within 2 business days, [[Support/bugzilla-sumo-lithium-component-owners|the component owner]] (<sup>A</sup>) triages the bug | ||
* Using magic :-) the person needinfo'd or assigned in triage will fix the bug in a timely fashion or at least move it forward in some way | * Using magic :-) the person needinfo'd or assigned in triage will fix the bug in a timely fashion or at least move it forward in some way | ||
| Line 17: | Line 17: | ||
* If the bug isn't a large feature that won't require a Lithium customization or a large amount of coding (again fuzzy!), '''set it to severity:enhancement. We won't use the other severities for now.''' | * If the bug isn't a large feature that won't require a Lithium customization or a large amount of coding (again fuzzy!), '''set it to severity:enhancement. We won't use the other severities for now.''' | ||
* If the triager doesn't know how to triage and/or how to prioritize the bug, then the triager should needinfo a MoCo manager like the SUMO manager, Patrick McClard, to help triage the bug. | * If the triager doesn't know how to triage and/or how to prioritize the bug, then the triager should needinfo a MoCo manager like the SUMO manager, Patrick McClard, to help triage the bug. | ||
* If the bug is a duplicate close it as a duplicate and point it to the original canonical bug. | |||
* If there's no hope of fixing the bug in the near future i.e. this quarter or next quarter, set to '''WONTFIX''' and leave a nice comment. Teams can only handle about 100 open bugs. | * If there's no hope of fixing the bug in the near future i.e. this quarter or next quarter, set to '''WONTFIX''' and leave a nice comment. Teams can only handle about 100 open bugs. | ||
* Finally and most importantly: '''THANK''' the bug filer if the filer isn't staff (it's nice to thank employees too :-) !) and leave a comment to indicate the bug was triaged | * Finally and most importantly: '''THANK''' the bug filer if the filer isn't staff (it's nice to thank employees too :-) !) and leave a comment to indicate the bug was triaged | ||
| Line 27: | Line 28: | ||
* All component owners: Once every six months (e.g. at All Hands) look at bugs that are: '''WONTFIX AND component: feature request or severity: enhancement''' and see if they need to be re-opened. | * All component owners: Once every six months (e.g. at All Hands) look at bugs that are: '''WONTFIX AND component: feature request or severity: enhancement''' and see if they need to be re-opened. | ||
=== | === Sprint Dates === | ||
SUMO follows the Mozilla marketing sprint dates which are documented in: | |||
https://wiki.mozilla.org/Support/SUMO_Project_management#Sprint_Planning | |||
= Do's = | = Do's = | ||
* Bugzilla isn't a meta discussion area; if you want to discuss workflow or meta e.g. how to triage,<br />please '''DO''' [https://support.mozilla.org/en-US/forums/contributors/new post your meta/workflow issue in a contributor forum thread] | * Bugzilla isn't a meta discussion area; if you want to discuss workflow or meta e.g. how to triage,<br />please '''DO''' [https://support.mozilla.org/en-US/forums/contributors/new post your meta/workflow issue in a contributor forum thread] | ||
* Do assume positive intent. 99% people are great :-) ; it's really hard to communicate with a positive tone in online writing! Much easier to appear to be not happy or mis-interpret others as being unhappy. | |||
* Do be concise and if you have multiple requests or questions, numbering them and placing them in a summary aka 'tl;dr' section at the beginning of your contributor forum post or bugzilla comment would be lovely. | |||
* Do be positive; we are super lucky to be working on a great open source software project like Mozilla and Firefox. | |||
= Don'ts = | = Don'ts = | ||
* '''Don't''' assign bugs to anybody if you aren't 100% sure the assignee agrees with your assignment and has time at the moment (<sup>D</sup>) | * '''Don't''' assign bugs to anybody if you aren't 100% sure the assignee agrees with your assignment and has time at the moment (<sup>D</sup>) | ||
* '''Don't''' worry if low priority bugs remain unassigned; this leaves bugs for volunteers and new folks to tackle | * '''Don't''' worry if low priority bugs remain unassigned; this leaves bugs for volunteers and new folks to tackle | ||
* '''Don't''' be a killjoy to new volunteers and users. New folks are great and don't have all the context and experience. Cheerfully and briefly help them and revel in the "beginner's mind" | |||
= Lithium specific stuff = | = Lithium specific stuff = | ||