Life Cycle of a SUMO bug
- A bug is created in the support.mozilla.org (Lithium) product
- Within 2 business days, component owner triages the bug
>>Does this mean Madalina? [roland] nope - every component owner is a triager which means all sumo employees are triagers for their components, e.g. i am the triager for the "Feature request" componnt
- 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:
>>Is the component owner the triager? Are there more triagers? - [roland] At the moment, the component owner is the triager for the component, and the 2nd person is the backup. I'm fine with adding other triagers like Philipp or volunteers later!
- 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
- 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
- >> [J99] We need a clear understanding and definition of Priorities and severities
Many of the hundred plus open bugs would be bugs that would be considered blockers had they occurred as a Kitsune change or as a Lithium breakage.
We need to make it clear that Bugzilla is listing important and very important bugs that are not getting assigned and not having a likely hood of being fixed.
The reason is not that the bug is minor. It may be a severe lack of functionality.
The reason is a lack of resources means severe issues will remain unfixed and only a small number the absolutely most severe ones get attention. John99 (talk) 03:44, 14 May 2017 (PDT)
>>Can we assume a perfect knowledge of the assignee's availability & issue fixing potential by the triager? - [roland] nothing is perfect, triagers do their best and if they can't figure it out they ask for help via needinfo or other methods
- 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
Do's
- Bugzilla isn't a meta discussion area; if you want to discuss workflow or meta e.g. how to triage, do post your meta/workflow issue in a contributor forum thread
>>Sounds more like a 'Don't' - [roland] yes please i would love suggestions for a real DO !
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
>>Does this increase the risk of a bug not being addressed in due time? - [roland] only low priority bugs; We don't have the resources to care about low priority bugs, if we had the people we could care about all bugs but that'll never happen in Mozilla :-)
- 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:
- Ask a member SUMO staff member to file a Lithium support case for you
>>Who should ask? The bug reporter or the triager? - [roland] The triager should ask. And if the triager is SUMO staff the triager should go ahead and file the Lithium support case. Only in exceptional circumstances would a non triager ask! Will clarify
- 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 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)