> > 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
