Here's my very lightweight counter-proposal: Once or twice a week, automatically mail out two lists (in one email) to the set of people Emma collected. The first are is UNCONFIRMED bugs. The second is NEW bugs, not filed by one of the reviewers or bug admins of that component, that haven't been touched in the last week. Highlight bugs from new Bugzilla registrations. The primary goal is to spot important regressions. The secondary goal is to respond to new contributors. Let the component owners own everything else about this process.
In short — shine a light on things, nothing more. This proposal: - Doesn't necessarily require extra meetings. The power and memshrink teams have been doing email triage with some success, and this is even lighter-weight. - Isn't a daily obligation. - Adapts to the processes, individuals, and capacity of each team. - Allows teams to manage their own costs (e.g., the value versus the cost of responding to every bug report individually). Improvements to tools will alter some of those cost-value equations to yield results that you'd prefer. Random inline replies below. > Many of our regressions are reported informally on Twitter, as GitHub >> issues, or on IRC. Those are spotted by engineers or QA who go looking, and >> those people file bugs. Those bugs, naturally, enter the funnel half-way >> along, skipping the pre-triage you propose. Can that be improved or >> leveraged? >> > The goal is that no bug will be able to skip the per-component > decision-making process. Emma will be experimenting with early groups to > figure out how to make this work. Why is that a goal? What you're suggesting is the exact opposite of the kind of distributed responsibility that we try to inculcate in maturing engineers. Is this why you think this has to be daily? If, say, Aaron files a critical bug, I trust him to set the right flags to go through our current triage processes, or work directly with engineering managers to find an assignee… and that can be quicker than even a daily triage, and avoids the need to process that bug. And if I file a NEW work-item bug, I don't want it to redundantly end up in a triage list the next day. We have "tracking-+", "P2", etc. bugs that will realistically never be >> addressed, because there's always more important work to do. What can we do >> to not lose sight of those and adjust priority accordingly? >> > > I don't know about P2 in this context, but I don't think that we can > afford to leave tracking+ bugs unassigned or unaddressed. That is an > essential part of our core quality focus. If a team is only working on > tracking+ bugs and is still understaffed, that is something we need to be > aware of and fix. A lot of this depends on your definition of quality. For example, we have 391 bugs in Firefox for Android that — at some point in the last three years — we decided were important (tracking+): http://mzl.la/1SC9IEg When considering the long-term success of a project, is it more important to triage non-nominated incoming bugs daily, or spend some time going through that list of 391 bugs to see what's slipping through the cracks, or re-triage existing product priorities? I think that's a fairly deep philosophical question. This is both true, and part of the problem. We cannot claim that we have a > focus on quality if we don't even have the resources to look at the > incoming bugs. The goal is to make daily bug triage very fast and painless. > I think Marco has a legit point here: even if triage is fast and painless, if nobody owns the component, then there's nobody to look at the bugs. And yes, that implies that — with this definition — there are components in which we don't have a focus on quality! I think you're more likely to have someone like Marco volunteer to triage bugs weekly, not daily — particularly if, as you say, there aren't many bugs filed per quarter. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
