Support/How SUMO uses bugzilla with Lithium: Difference between revisions

← Older edit

Support/How SUMO uses bugzilla with Lithium (view source)

Revision as of 16:26, 1 June 2017

1,790 bytes added , 1 June 2017

→‎Followup at the beginning of every marketing sprint: link to sprint dates

Rtanglao

Confirmed users

5,365

edits

@@ Line 7: / Line 7: @@
 = Life Cycle of a SUMO Lithium bug =
 * A bug is created in the support.mozilla.org (Lithium) product
-* Within 2 business days, [[User:Rtanglao/bugzilla-sumo-lithium-component-owners|component owner]] (<sup>A</sup>) triages the bug
+* 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
@@ 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)
 * 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 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 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
+== During a sprint ==
+* assignees to bugs for that sprint, move their bugs forward daily
 == 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.
-=== Q2 2017 Sprints ===
+=== Sprint Dates ===
-* Sprint 3, starts May 15, ends Wed May 31, 2017
+SUMO follows the Mozilla marketing sprint dates which are documented in:
-* Sprint 4, stats Monday June 5, 2017
-=== Q3 2017 Sprints ===
+https://wiki.mozilla.org/Support/SUMO_Project_management#Sprint_Planning
-* Sprint 1
-* Sprint 2
-* Sprint 3
-* Sprint 4
 = 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]
+* 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'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''' 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 =