Proposed Updates to Layout triage process

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposed Updates to Layout triage process

Maire Reavy
Hi Layout folks,

tl;dr -- This is all about updating our triage process for handling open
Layout bugs.  If you aren’t interested in triage, you can stop reading now.

Following up on discussions from last week’s Layout standup meetings, I’d
like to propose changing how we approach Layout triage.


   1.

   Before getting into that, I need to know who considers themselves to be
   very knowledgeable of each component.  I’ve created a doc to capture that
   <https://docs.google.com/document/d/1w3glqHf3bLSMq3iwjHIJVR1pQuHpb0bM1FLrXXasG3s/edit>.
   If you consider yourself knowledgeable, please add your name or irc nick
   next to the component.  Some of you have done that already - thank you! My
   goal is to have 3 or more names next to each component by next the middle
   of next week.
   2.

   Problem statement; Currently the Layout manager triages all Layout bugs,
   and there are a lot of Layout bugs.  It’s really a job for more than one
   person. In practice the Layout manager counts on various Layout developers
   keeping an eye on the bugs, but none of those devs mark priority or comment
   regularly to let others know they’ve been reviewed.
   3.

   Purpose of this change: I want to eliminate (as best we can) any single
   points of failure on triage and ensure that no bug sits for more than 2-3
   business days without getting triaged.  Most importantly, I want us to
   ferret out important bugs as early as we can so we have the maximum time to
   fix them.
   4.

   The Layout team can try any reasonable approach it wants to triage.
   Here are two approaches that seem to have worked well for other teams at
   Mozilla:
   1.

      Round robin = everyone on the team takes turns triaging bugs
      2.

      Triage buddy = a small group of experts for that component (typically
      the developers who have written and/or modified code in that component)
      triage regularly amongst themselves

* There are pros and cons to each approach, and they were discussed in the
standup meetings this past week.

   1.

   After talking with the team about this in this week’s standups, I’m
   leaning toward the triage buddy approach.


Thoughts are welcome.  I’m most interested in hearing from people who work
regularly in the Layout code; they are the ones with real “skin in the
game” though I’m happy to hear thoughts from anyone.

If I get no comments, we’ll go with the triage buddy approach and see how
well it works for us.

If you haven’t done so already, please look at the first item (1) above and
add your name to the doc I reference -- specifically next to the components
you feel knowledgeable of and capable of triaging bugs for.

NOTE: The list of triage buddies will change and grow as we grow Layout
peers.  I will ask everyone on the Layout team to take a look once a
quarter at this list and consider adding their names to components they
have modified recently.

Questions?  Please ping me or email me privately.  I want this thread to
stay focused on discussing which approach we want to take.  Again, in lieu
of comments, we’ll go with triage buddy and see how well it works for us.

Cheers,

-Maire

--
Maire Reavy
[hidden email]
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Updates to Layout triage process

Emilio Cobos Álvarez
Trying the triage buddy approach sounds good to me, fwiw.

Related to that, should we try to do something like what the build team
does for reviews?

In particular, I notice that some of my patches can be reviewed by
whoever gets there first. Right now I need to choose a reviewer, which
may be more or less backlogged with other duties.

The build team has a bugzilla user they all watch and that acts as a
queue of "reviews to be done by build peers". That way there's no single
build peer overbooked with reviews while others may be more idle and
equally qualified to review a given patch.

We could consider doing the same for layout. Of course if a patch should
definitely be reviewed by a given person, it's better to tag that
specific person. But for patches like cleanups / dead code removals /
etc, it may work better this way.

What do people think about this?

  -- Emilio

On 5/21/18 6:02 AM, Maire Reavy wrote:

> Hi Layout folks,
>
> tl;dr -- This is all about updating our triage process for handling open
> Layout bugs.  If you aren’t interested in triage, you can stop reading now.
>
> Following up on discussions from last week’s Layout standup meetings, I’d
> like to propose changing how we approach Layout triage.
>
>
>     1.
>
>     Before getting into that, I need to know who considers themselves to be
>     very knowledgeable of each component.  I’ve created a doc to capture that
>     <https://docs.google.com/document/d/1w3glqHf3bLSMq3iwjHIJVR1pQuHpb0bM1FLrXXasG3s/edit>.
>     If you consider yourself knowledgeable, please add your name or irc nick
>     next to the component.  Some of you have done that already - thank you! My
>     goal is to have 3 or more names next to each component by next the middle
>     of next week.
>     2.
>
>     Problem statement; Currently the Layout manager triages all Layout bugs,
>     and there are a lot of Layout bugs.  It’s really a job for more than one
>     person. In practice the Layout manager counts on various Layout developers
>     keeping an eye on the bugs, but none of those devs mark priority or comment
>     regularly to let others know they’ve been reviewed.
>     3.
>
>     Purpose of this change: I want to eliminate (as best we can) any single
>     points of failure on triage and ensure that no bug sits for more than 2-3
>     business days without getting triaged.  Most importantly, I want us to
>     ferret out important bugs as early as we can so we have the maximum time to
>     fix them.
>     4.
>
>     The Layout team can try any reasonable approach it wants to triage.
>     Here are two approaches that seem to have worked well for other teams at
>     Mozilla:
>     1.
>
>        Round robin = everyone on the team takes turns triaging bugs
>        2.
>
>        Triage buddy = a small group of experts for that component (typically
>        the developers who have written and/or modified code in that component)
>        triage regularly amongst themselves
>
> * There are pros and cons to each approach, and they were discussed in the
> standup meetings this past week.
>
>     1.
>
>     After talking with the team about this in this week’s standups, I’m
>     leaning toward the triage buddy approach.
>
>
> Thoughts are welcome.  I’m most interested in hearing from people who work
> regularly in the Layout code; they are the ones with real “skin in the
> game” though I’m happy to hear thoughts from anyone.
>
> If I get no comments, we’ll go with the triage buddy approach and see how
> well it works for us.
>
> If you haven’t done so already, please look at the first item (1) above and
> add your name to the doc I reference -- specifically next to the components
> you feel knowledgeable of and capable of triaging bugs for.
>
> NOTE: The list of triage buddies will change and grow as we grow Layout
> peers.  I will ask everyone on the Layout team to take a look once a
> quarter at this list and consider adding their names to components they
> have modified recently.
>
> Questions?  Please ping me or email me privately.  I want this thread to
> stay focused on discussing which approach we want to take.  Again, in lieu
> of comments, we’ll go with triage buddy and see how well it works for us.
>
> Cheers,
>
> -Maire
>
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Updates to Layout triage process

Boris Zbarsky
In reply to this post by Maire Reavy
On 5/22/18 8:08 AM, Emilio Cobos Álvarez wrote:
> What do people think about this?

I think it's worth trying.  What do the build peers do to "claim" a
review so two people don't duplicate work doing the same review?

-Boris
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Updates to Layout triage process

Emilio Cobos Álvarez
On 5/22/18 4:41 PM, Boris Zbarsky wrote:
> On 5/22/18 8:08 AM, Emilio Cobos Álvarez wrote:
>> What do people think about this?
>
> I think it's worth trying.  What do the build peers do to "claim" a
> review so two people don't duplicate work doing the same review?

They redirect the request to themselves before starting reviewing, so
the flag would change from r?Layout, then r?particularReviewer, then
r{+,-,cleared}.

  -- Emilio
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Updates to Layout triage process

Maire Reavy
In reply to this post by Boris Zbarsky
On Tuesday, May 22, 2018 at 10:48:06 AM UTC-4, Emilio Cobos Álvarez wrote:

> On 5/22/18 4:41 PM, Boris Zbarsky wrote:
> > On 5/22/18 8:08 AM, Emilio Cobos Álvarez wrote:
> >> What do people think about this?
> >
> > I think it's worth trying.  What do the build peers do to "claim" a
> > review so two people don't duplicate work doing the same review?
>
> They redirect the request to themselves before starting reviewing, so
> the flag would change from r?Layout, then r?particularReviewer, then
> r{+,-,cleared}.
>
>   -- Emilio

Let's go with the "triage buddy" approach.  We'll need to have a reasonable number of triagers for each sub-component, and then we'll start.  

Here's the current list of triagers for each sub-component: https://docs.google.com/document/d/1w3glqHf3bLSMq3iwjHIJVR1pQuHpb0bM1FLrXXasG3s/edit 

NOTE: You don't need to be an expert to sign up for triage -- just have a self-driven willingless to work hard at it regularly. I recommend fixing bugs in the components you want to triage as a first start.  (FYI: My plan is for each sub-component to have at least 2 experts who are triaging -- so they can grow new triagers.)

-Maire


_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout