User talk:Rtanglao/bugzilla-sumo-lithium

From MozillaWiki
Jump to: navigation, search

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)

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

>> Not too helpful as above in my opinion [J99]
  • This may well result in priorities only changing when a bug is in a sprint and assigned. We can easily see whether or not a bug is assigned.
  • That is more of a milestone.
  • It can be handled in a whiteboard comment to show the sprint it is allocated to.
  • It does not indicate the actual severity of a bug.
  • We currently have near on 200 open bugs many of those may well be important or very important relating to lost or absent features.
  • We may need to accept due to lack of resources a particular bug will not be fixed, But bugzilla needs to indicate it is an important or serious issue that is waiting to be fixed as and when resources become available. John99 (talk) 05:38, 18 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

>>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
>> [J99] But many other bugs get in the same unasigned bucket. It means important bugs do not get fixed
  • Volunteers and new folks
    • Are not Lithium Admins so can not make changes to Sumo Lithium
    • Are not able to file or see Lithium Cases
    • High priority and sever bugs will remain unfixed.
      Redirects and related showfor bugs, documentation etc issues have been around for the three months since the migration, and in many cases were identified as likely issues in or prior to the beta testing.
    • Even if bugs are assigned and high priority recent experience indicates they still may not be actioned & resolved quickly, but if they are assigned it is up to the module owner and asignee to follow up and Bugzilla is at least enabling us to see & manage the situation. John99 (talk) 04:06, 14 May 2017 (PDT)

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)
Retrieved from "https://wiki.mozilla.org/index.php?title=User_talk:Rtanglao/bugzilla-sumo-lithium&oldid=1171449"