Richard, Many components have watchers, I am grateful for that. Some components don't. We need reviews in all components so we don't lose track of bugs we must fix to avoid a point release.
We're applying consistent process across all components, because we must reduce the amount of noise in bugzilla. Anyone should be able to see what we are doing, what we agree to do later, and what we're not going to do and not have to know the metadata folklore of each component to do it. This means there's going to be changes in how teams use bugzilla metadata. We don't want to waste engineering's time, so we're piloting this with a small number of groups so we can see if we're going in the right direction, and stated what we expect to see happen with this work so we can decide if we'll continue with it. -- Emma Humphries On Fri, Jan 29, 2016 at 4:17 PM, Richard Newman <rnew...@mozilla.com> wrote: > Starting in the second quarter of this year, if you’ve taken on a >> component, I’m expecting you or your team to look at the bugs which landed >> in the component on a more frequent basis than a weekly triage. >> > > In my experience, component watching adequately serves this purpose, and > component watchers collaboratively respond to, immediately triage, or flag > with a tracking-? flag. That might not be true for some components, but it > is for the three products I watch. > > >> Assigned to a developer, release tracking flags nominated, and set at >> priority `P1`. If the bug is being worked on by somebody from outside your >> core team, a team mentor should be assigned. >> > > I think it's worth pointing out that it's not always worth assigning bugs > to a developer — in my experience that does more harm than good if they're > not working on it. Be realistic. Neither does P1 mean anything useful in > many of the components I follow. > > Perhaps it would be worth taking a step back and explaining what problem > you're trying to solve here, and why you think that problem is the one we > should be solving? > > Again, speaking from my experience, re-triaging and re-processing the > backlog within the context of current product priorities seems to be much > more of a neglected task than processing the handful of new bugs that > arrive each day — it's rare for a new bug to slip through the cracks in the > Fennec component, but we have a long list of old bugs that we triaged, > declared important, and never looked at again. > > You will have a really hard time trying to get buy-in on this process > without demonstrating that there is significant benefit in the additional > time investment. > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
