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