It seems to me that when this bug program was started, it had these two goals (quoted from Emma's previous email):
"First, we want to make better assertions about the quality of our releases by making clear decisions about which bugs must be fixed for each release (urgent) and actively tracking those bugs. The other is the number of good bugs filed by our community. Filing a bug report is a gateway to greater participation in the Mozilla project, and we owe it to our community to make quick and clear decisions about each bug." Somewhere along the way this got conflated with "all teams must use the same process to indicate how bugs got triaged". While I'm sure that doing so provides additional benefits, I'm not sure it's necessary to accomplish the goals stated above, and might actually be counterproductive initially. Some teams already have processes in place for triaging and annotating bugs, and have been using their process for quite some time. Forcing them into a new process seems unnecessary if what they are doing already works for them. I think what's more important is that each component have an owner (or owners), and that the triage process for that component is documented somewhere and followed. For those teams that don't already have a triage process or that are looking to change their process, I think it's a great idea to have a canned "this is the recommended approach we know has worked for some teams" ready for them to use. Dictating specific process rather than allowing teams to find their own way to meet the requirements is overkill. If you do want to expand the scope of this proposal to add more uniformity across Mozilla then that should be explicitly stated as a goal. Personally, I think that might be better done as a follow-up effort after looking at the variety of triage processes that different teams use and finding something that is general enough to work for everybody. Cheers, kats On Fri, Apr 1, 2016 at 4:35 AM, Marco Bonardo <mbona...@mozilla.com> wrote: > On Fri, Apr 1, 2016 at 2:02 AM, Emma Humphries <e...@mozilla.com> wrote: > >> Priority sounds like a great choice, but given that everyone's using the >> Priority field their own way, there's enough heterogeneity in how it's used >> to make it difficult. >> > > Fwiw, we (Awesome Search Team) also use Priority for the backlog, and we > consider P1, P2 and P5 the same as Media Playback team. So there is some > convergence about the meaning of those. > Though we also use P3 for "we care about this and will fix it, provided > there's no major priority bug to fix first". This helps planning future > work, by retriaging P3s into P2s when the list of P2s shrinks or new goals > are made. The P5 pool would be too large to pick things out of it. > Merging P4 into P5 wouldn't make much of a difference. Both are things we > recognize are valid bugs, but it's very unlikely we'll ever have time to > fix them. > > Imo, merging everything below P2 into a single backlog is a mistake, > there's quite a huge difference between "we want to fix this once there's > time but it's not critical now" to "we are unlikely to ever have time to > fix this". I personally feel the need for a "P3" category. > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
