Confirmed users
5,365
edits
Support/How SUMO uses bugzilla with Lithium: Difference between revisions
Jump to navigation
Jump to search
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
(remove disclaimer) |
(→Followup at the beginning of every marketing sprint: link to sprint dates) |
||
| (7 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 13: | Line 13: | ||
* If missing, ask the bug reporter for relevant follow up information to ensure the bug is actionable (e.g. if info is incomplete like missing: steps to reproduce, what actually happened, expected result) | * If missing, ask the bug reporter for relevant follow up information to ensure the bug is actionable (e.g. if info is incomplete like missing: steps to reproduce, what actually happened, expected result) | ||
* Change to the correct product and/or component if the product and/or component are wrong | * Change to the correct product and/or component if the product and/or component are wrong | ||
* Fix the prioritization if it is wrong. This is fuzzy: P1 = fix ASAP, or this sprint, P2 = fix next sprint, P3-P5 we will get to it someday perhaps | * Fix the prioritization if it is wrong. This is fuzzy: P1 = fix ASAP, or this sprint, P2 = fix next sprint, P3-P5 we will get to it someday perhaps; use P5 for "good first bug" | ||
* '''If the bug is high priority''', then flag it via needinfo'ing the right person or assigning if and only if you know 100% the assignee has time to do it and can do it. And file an Lithium support case if required.(<sup>C</sup>) | * '''If the bug is high priority''', then flag it via needinfo'ing the right person or assigning if and only if you know 100% the assignee has time to do it and can do it. And file an Lithium support case if required.(<sup>C</sup>) | ||
* 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. | |||
* 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 | ||
== During a sprint == | |||
* assignees to bugs for that sprint, move their bugs forward daily | |||
== Followup at the beginning of every marketing sprint == | == Followup at the beginning of every marketing sprint == | ||
At the beginning of every marketing sprint (sprints last 2 weeks, so approximately every 2-2.5 weeks), the component owners should ensure that the bugs in their component are prioritized correctly and that all high priority bugs are moving forward. | * At the beginning of every marketing sprint (sprints last 2 weeks, so approximately every 2-2.5 weeks), the component owners should ensure that the bugs in their component are prioritized correctly and that all high priority bugs are moving forward. | ||
* All: Try to zero your needinfos at the beginning of every sprint. If you can't, ask for help or needinfo somebody else or leave the needinfo if it's a low priority bug. Needinfos shouldn't be a burden. More important to move the current sprint, high priority bugs forward. | |||
* 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 = | ||