Support/How SUMO uses bugzilla with Lithium

From MozillaWiki
< Support
Revision as of 07:12, 1 June 2017 by Rtanglao (talk | contribs) (copy from https://wiki.mozilla.org/User:Rtanglao/bugzilla-sumo-lithium)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

disclaimer: DRAFT PROPOSAL work in progress, needs review

disclaimer: this is Roland's PROPOSAL of how bugzilla could work for SUMO, today's process isn't very well defined so we all work inconsistently, this page is an attempt to get some consistency (and it may contradict what we are doing today :-) !)

Audience: Those who file and comment on bugs related to SUMO and Lithium.

Confused by this?: Please contact the SUMO team.

Life Cycle of a SUMO Lithium bug

  • A bug is created in the support.mozilla.org (Lithium) product
  • Within 2 business days, component owner (A) 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

Triage consists of the following (B):

  • 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
  • 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.(C)
  • 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.
  • 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

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.

Q2 2017 Sprints

  • Sprint 3, starts May 15, ends Wed May 31, 2017
  • Sprint 4, stats Monday June 5, 2017

Q3 2017 Sprints

  • Sprint 1
  • Sprint 2
  • Sprint 3
  • Sprint 4

Do's

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 (D)
  • Don't worry if low priority bugs remain unassigned; this leaves bugs for volunteers and new folks to tackle

Lithium specific stuff

If a Lithium support case needs to be filed for a bug:

  • If you know the bug needs a Lithium support case, please ask a SUMO staff member to file a Lithium support case for you. Triagers should be able to figure out if a Lithium support case is needed if you are un-certain.
  • Unfortunately however the SUMO staff triager will probably have figure out when it's appropriate to file a Lithium support case. It's not a line that's obvious to non SUMO staff or volunteers; the very hazy line is that anything that isn't fixable in Lithium settings needs a Lithium support case.

The SUMO staff member should:

  • File the Lithium support case and in the "Additional Notes" field of the Lithium support case link to the bugzilla bug which we like to call the "shadow" bug
  • In the bugzilla "shadow" bug:
    • Add the case number to the bugzilla summary and whiteboard (E) using the convention: [li-<case>] e.g. [li-00134461]
    • Add a link to the case (e.g. https://supportcases.lithium.com/50061000009MCTs) in the bugzilla field: Details -> URL field
    • As updates are received from the not-public Lithium case system, copy and paste them into the bug (at least the updates that are relevant)

NOTES

  • (A) Component owners are SUMO employees for now, could be volunteers or other employees in the future
  • (B) Is the component owner the triager? Are there more triagers? Answer: At the moment, the component owner is the triager for the component, and the backup component owner is the backup triager. Again fine with adding other triagers e.g. experienced volunteers and other employees in the future
  • (C) Can we assume a perfect knowledge of the assignee's availability & issue fixing potential by the triager? A: Nothing is perfect, triagers do their best and if they can't figure it out they ask for help via needinfo or other methods
  • (D) Does this increase the risk of a bug not being addressed in due time? A: only low priority bugs; unfortunately we don't have the resources to spend a lot of time on low priority bugs, if we had the people we could fix and focus on all bugs but that'll never happen in Mozilla :-)
  • (E) What about other whiteboard keywords like "[1st2weeks]"? Answer: all other "pre-switchback-to-kitsune-temporarily" whiteboard keywords e.g. "[1st2weeks]" are obsolete. Got some ideas for useful whiteboard keywords (they are just free form "tags" like instagram or flickr tags)? Please email rtanglao AT mozilla.org or start a SUMO contributor forum thread.
Retrieved from "https://wiki.mozilla.org/index.php?title=Support/How_SUMO_uses_bugzilla_with_Lithium&oldid=1172395"