Platform/GFX/TriageSchedule

Overview

This is a pilot project starting in 2015. The goal is to refine the process enough to understand what kind of time load this requires, what kind of latency we can accomplish, and collect enough data for a retrospective about best ways to measure the progress, any possible changes and next steps.

Process

• This is a rotating duty. Each individual will be in charge of a week worth of new bugs, assigned to nobody, starting Saturday, ending Friday. You would then have one extra week to act on them, so that a bug is at most 14 days old by the time somebody looks at it.
• At this pace, everybody will get this duty once per quarter. The schedule is in the shared calendar (see above), and it should be self-managing - if you want to trade your week with somebody else, you should be able to just move the item around.
• The goal is to make sure we don’t miss something important, completely or until “late”, and also notice any trends we may have with crashes or intermittent failures, or in any particular areas of the code. The idea is to categorize the bugs as they come in so that we know which ones need a jump on, which ones can wait a bit, maybe ask for some information that is missing, maybe CC the right people, etc.
• We will cover these components: Canvas: 2D, Canvas: WebGL, GFX: Color Management, Graphics, Graphics: Layers, Graphics: Text, Image Blocking, ImageLib, Panning and Zooming.
• Some guidelines:
  • A good guideline should be ~15 minutes per bug, which is probably about hour and a half a day for the two weeks, but lets see what we really need as we get going.
  • This isn’t about finding a cause, and it isn’t about the full prioritization.
  • This is about noticing things sooner.
  • This is about asking the bug author for info that may be missing or would help with the triage.
  • This is about asking for a regression range, or even getting one if you can reproduce the problem and you have time.
  • This is about CC-ing the people on the team (or elsewhere) you’re guessing could shed more light on the issue.
  • This is about doing an occasional needinfo, and should be reserved for what you deem is a high priority.

Schedule

The schedule is tracked in a shared calendar, ID mozilla.com_6059q0oha1t7ueamb52cs7vegk@group.calendar.google.com and in case of difference with that and the table below, the shared calendar wins.

2015 Q1	2015 Q2	2015 Q3	2015 Q4
Jan 3 - Jan 9 Milan Jan 10 - Jan 16 Kats Jan 17 - Jan 23 Bas Jan 24 - Jan 30 David Jan 31 - Feb 6 Benoit Feb 7 - Feb 13 Dan Feb 14 - Feb 20 Sotaro Feb 21 - Feb 27 Jeff Gilbert Feb 28 - Mar 6 Timothy Mar 7 - Mar 13 Nicolas Mar 14 - Mar 20 Botond Mar 21 - Mar 27 Jeff Muizelaar Mar 28 - Apr 3 Mason	Apr 4 - Apr 10 Milan Apr 11 - Apr 17 Dan Apr 18 - Apr 24 Kats Apr 25 - May 1 Bas May 2 - May 8 David May 9 - May 15 Sotaro May 16 - May 22 Jeff Gilbert May 23 - May 29 Timothy May 30 - June 5 Nicolas June 6 - June 12 Botond June 13 - June 19 Jeff Muizelaar June 20 - June 26 Milan June 27 - July 3 Mason	July 4 - July 10 Benoit

Future considerations

This is something JS team did at one point; when we're considering the next steps on this, we will want to consider it:

JS team tried shared-triage-responsibility a few years ago. It didn't last very long, but it was not scheduled or enforced. Eventually managers/project managers/tech leads took over for the sub-components they were responsible for.

Before JS did coordinated triage, Dave Mandelin measured that there were about 11 new bugs per day, half of which were internally generated by the team and didn't need triage (developers triage their own bugs). So that was about 5/6 bugs a day across the component. Of those, the most serious ones (~2 a week, I think?) were already getting fixed within a release cycle. Based on the distribution we ended up with three priority tags:

   p1 = must do
   p2 = want to do <- general bucket
   p3 = may do <- usually idea/investigation/research bugs

And two follow-up tags:
   investigate = someone needs to spend a few minutes investigating
   nonactionable = nothing to do

Thoughts and comments about the first round

• (Milan) Worth revisiting the query for the bugs you've triaged a few days, or a week after you've reduced the number to zero - sometimes the new ones show up because of the component change or bug getting reopened, or some such.
• (Kats) Current method gives people exposure to other parts of the the code, but without sufficient context to properly triage bugs (no history of what landed recently, or if other similar bugs were reported in the past week). I would still prefer a component-watching approach
• (Kats) Intermittents are more challenging to deal with - if it's a low-volume initially and later increases in volume who is responsible for it?