On Fri, Apr 1, 2016 at 9:30 AM, Lawrence Mandel <lman...@mozilla.com> wrote:
> On Fri, Apr 1, 2016 at 8:17 AM, Kartikaya Gupta <kgu...@mozilla.com> > wrote: > >> 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. > > > We have already started tracking those bugs - the real mustfix list - with > the blocking value for the tracking flag. > > >> 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. >> > > I think we need to have a uniform way of identifying bugs that matter to a > release. Having a different mechanism for each team means that we're likely > to miss something. > > I think some level of flexibility about how a team manages the rest of > their bugs can work. Each component differs in team composition, the way > the team works, and the type of work that they have to do. A one size fits > all approach may not be our best option. > I meant to add one more thought in here. I appreciate Emma's effort to make Bugzilla more consistent. The lack of consistency makes it hard to query and track across the project and I think has resulted in us missing bugs that we should have caught. Perhaps we can get consistency by defining what it is that we need to know and having each team map their process to that information so that we can create advanced queries (instead of the simple ones that we use today) that do work across teams. Or, perhaps there is a set of things that we want to track uniformly - like blockers, regressions, major user visible issues, web compat issues, etc - that can be tracked independent of team process. > > Lawrence > > >> >> 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 >> > > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
