Open Bug 1428853 Opened 4 years ago Updated 4 years ago

migrate to owner triaged the top 50 bugzilla components with high frequency failures


(Testing :: General, enhancement, P3)



(Not tracked)


(Reporter: jmaher, Unassigned)


(Blocks 1 open bug)


there is a list here:

we will need to do:
Core::Audio/Video: Playback
Core::CSS Parsing and Computation
Firefox::Developer Tools: Debugger
Testing::Firefox UI Tests
Core::Build Config
Core::DOM: Security
Firefox::Developer Tools: Console
Release Engineering::Buildduty
Firefox::Session Restore
Core::Disability Access APIs
Firefox::New Tab Page
Firefox::Tabbed Browser
Firefox::Developer Tools: Inspector
Release Engineering::General Automation
Firefox for Android::General
Core::WebRTC: Audio/Video
Core::Layout: Text
Toolkit::Password Manager
Core::JavaScript: GC

Please note that some of these components have no team associated with them, and the triage owner is there as they edited the code once upon a time.  The goal is to get all of these done, but we can call this bug resolved if there are a few remaining issues for reasons such as:
1) no team, real ownership
2) no existing triage process defined
3) valid reason TBD
For people not in the loop, why are we doing this, and what does it entail?
Hi Nathan- this is a great question.

Right now there are 40+ bugs that are high frequency intermittent failures (30+ times/week) that we determine are a priority for someone to look at.  Spread out across teams, this is <3 new failures/week, typically about 1-2/week for our larger components.  Each component has a triage owner already defined:

and now for test failures they are associated to the correct bugzilla component.  In 2017 we have been manually spending a lot of time doing this process of essentially asking the triage owner to find someone to look at the bug.  To date we have 67 components where the owners look at intermittent-failure bugs already in their typical weekly/daily triage.  

The goal here is to work with the triage owners and determine their triage process and make sure we flag the bugs correctly while handing off our expectations and rules that we function within.  Typically when we do this we run some queries to get an idea of the volume so we can give a rough idea of what to expect based on the data from 2017.

In the end, the stockwell team can focus on writing tools and making bugs easier to debug instead of barely able to keep up with triage.  Likewise the teams which own code can focus on bugs that are causing problems for all developers and be more self sufficient without us having full time resources triaging bugs for all teams.
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.