Improving triage process

[Soledad Penadés]

Hello!

We discussed triage a while ago: it actually seems like each subteam at
DevTools has a different way of doing triage; even each person can have
a different way!

I don't think this is a good situation to be in, so I have summarised
the existing doc[1] and my experience of triaging in other projects and
whatever I could copy from the debugger.html process down to a one page
triage workflow:

https://docs.google.com/document/d/1sZAj77LDLH4oqR9TA4RlFubk_Kio0MHXfiVTjZldiTs/edit?usp=sharing

The idea is that we would start at the top, asking the easiest questions
first and attempting to turn the bug into 'actionable' at the end of the
triage. As you progress through the stages, the questions become more
complicated and it might require a more experienced engineer. This gives
us a chance to make the triage process accessible to less experienced
contributors--including new members of the team, instead of starting
with the hardcore questions first.

By removing uncertainty and making this a somewhat "mechanical" process,
there's higher chances we can look at bugs faster.

I would like to know if I have captured all the questions here. Is there
anything I missed? Please add comments or respond to this email! This
document will finally live in the docs/ folder, so it's easily in sight
of everyone that comes to the project, unlike a google doc that has very
low discoverability

The aim is to...

- reduce the time it takes for bugs to be resolved
- reduce the number of bugs we have "in store"
- hold open periodic triage meetings where anyone (not only staff) can
join and triage
- perhaps collaborate with QA team in their community verification
efforts:
https://wiki.mozilla.org/Bugdays/Bug-verification#How_to_Verify_bugs and
any other similar processes to open our team up and make it more
approachable to external collaborations

Thanks!

sole


[1] the existing doc
https://docs.google.com/document/d/1uG0foc0pphXJB489_8ClKjYr1wbRXeFyrkd_kIOv9ao/edit#heading=h.4malzscwtuir


--

http://soledadpenades.com

[Patrick Brosset]

Thank you Sole for this initiative.
I have made comments in the doc.

If you are doing triage, please read and consider improving the doc!

> _______________________________________________
> dev-developer-tools mailing list
> dev-devel...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-developer-tools
>

[Soledad Penadés]

Thanks! I've addressed some of the comments in the doc.


There's also the official Firefox triage process; Patrick mentioned
parts of it in the comments:

https://wiki.mozilla.org/Bugmasters/Process/Triage

There seem to be a few tools for triaging, like
https://mozilla.github.io/triage-center/

For example this will give us the bugs to look at for our general
component "Firefox Developer Tools":

https://mozilla.github.io/triage-center/?component=Firefox%3ADeveloper+Tools


I have two concerns with the triage system so far, which unfortunately I
didn't capture in my early email:

1) the product team doesn't seem to have a say in order to prioritise
and build a cohesive experience.

And so if we mark a thing as "P5, we won't implement it, but will accept
patches" we end up with features that might not be maintained in the
future, but we "had to" merge because we were sent a patch.

2) bugzilla might not be the best place for feature requests.

Many bugs requesting features or providing ideas stay open and
"unactioned" for years, because we cannot implement them now, but we
can't give an answer either such as "when" or even "ever" will it be
implemented. I'm starting to think that feature request bugs should be
closed with an acknowledgment and thank you, and moved to a special
document or whatever area you think of, where they can be taken into
account by product management.

This way we would a) take action b) reduce the volume of open bugs

Otherwise it just keeps growing and growing and at some point it's
psychologically unapproachable.

Thoughts?

On 23/08/2017 14:20, Patrick Brosset wrote:
> Thank you Sole for this initiative.
> I have made comments in the doc.
>
> If you are doing triage, please read and consider improving the doc!
>
> On Wed, Aug 23, 2017 at 2:08 PM, Soledad Penadés <so...@mozilla.com
> <mailto:so...@mozilla.com>> wrote:
>
> Hello!
>
> We discussed triage a while ago: it actually seems like each
> subteam at DevTools has a different way of doing triage; even each
> person can have a different way!
>
> I don't think this is a good situation to be in, so I have
> summarised the existing doc[1] and my experience of triaging in
> other projects and whatever I could copy from the debugger.html
> process down to a one page triage workflow:
>
> https://docs.google.com/document/d/1sZAj77LDLH4oqR9TA4RlFubk_Kio0MHXfiVTjZldiTs/edit?usp=sharing

> <https://docs.google.com/document/d/1sZAj77LDLH4oqR9TA4RlFubk_Kio0MHXfiVTjZldiTs/edit?usp=sharing>

>
> The idea is that we would start at the top, asking the easiest
> questions first and attempting to turn the bug into 'actionable'
> at the end of the triage. As you progress through the stages, the
> questions become more complicated and it might require a more
> experienced engineer. This gives us a chance to make the triage
> process accessible to less experienced contributors--including new
> members of the team, instead of starting with the hardcore
> questions first.
>
> By removing uncertainty and making this a somewhat "mechanical"
> process, there's higher chances we can look at bugs faster.
>
> I would like to know if I have captured all the questions here. Is
> there anything I missed? Please add comments or respond to this
> email! This document will finally live in the docs/ folder, so
> it's easily in sight of everyone that comes to the project, unlike
> a google doc that has very low discoverability
>
> The aim is to...
>
> - reduce the time it takes for bugs to be resolved
> - reduce the number of bugs we have "in store"
> - hold open periodic triage meetings where anyone (not only staff)
> can join and triage
> - perhaps collaborate with QA team in their community verification
> efforts:
> https://wiki.mozilla.org/Bugdays/Bug-verification#How_to_Verify_bugs

> <https://wiki.mozilla.org/Bugdays/Bug-verification#How_to_Verify_bugs>

> and any other similar processes to open our team up and make it
> more approachable to external collaborations
>
> Thanks!
>
> sole
>
>
> [1] the existing doc
> https://docs.google.com/document/d/1uG0foc0pphXJB489_8ClKjYr1wbRXeFyrkd_kIOv9ao/edit#heading=h.4malzscwtuir

> <https://docs.google.com/document/d/1uG0foc0pphXJB489_8ClKjYr1wbRXeFyrkd_kIOv9ao/edit#heading=h.4malzscwtuir>

>
>
> --
>
> http://soledadpenades.com
>
> _______________________________________________
> dev-developer-tools mailing list
> dev-devel...@lists.mozilla.org

> <mailto:dev-devel...@lists.mozilla.org>
> https://lists.mozilla.org/listinfo/dev-developer-tools
> <https://lists.mozilla.org/listinfo/dev-developer-tools>
>
>

--
http://soledadpenades.com

[Julian Descottes]

Thanks for doing that!

Added a couple of comments, I would like to have an easy way to have a
bugzilla queries for our bugs.
We could see the early triage as a 3-steps process:
- doesn't have "need-information" and doesn't have a priority
-> we should contact the component owner to take a look
- has "need-information" (unclear? unreproducible? not actionable?)
-> there is an active need-info, and the bug should be reviewed
regularly. In case we receive no answer, close the bug
- has a priority
-> normally the bug should be reproducible and actionable at the stage

If we can have queries to easily identify bugs in step 1 and step 2, as
well as deadlines for each step, I think it could help us monitor the
triage of new bugs.A prerequisite for this to work would be to assign a
priority to all our older bugs.

> https://lists.mozilla.org/listinfo/dev-developer-tools
>