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
dev-tech-layout@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-layout
