On Fri, Apr 1, 2016 at 8:33 AM, Milan Sreckovic <msrecko...@mozilla.com> wrote:
> Valid point. > > Being able to tell the status of “other team’s bugs” is critical for some > number of people that look at bugs across all teams. A number of > directors, release management, I’m sure a sizeable number. I would still > guess a minor though; I know I am completely unaffected by the P’s and Q’s > that the media team uses, and don’t care if they are different from what > E10S is using. And whatever they have seems to be working for them. > > If it is important for everything to be the same, we need to consider the > multiplier. For example, if it’s going to make life twice as easy for > Lawrence (hi Lawrence), but make it 10% more difficult for all the > developers - I’d say we shouldn’t do it. If it’s going to let us have > better decision making because we can extract some data out of bugzilla > that we otherwise couldn’t, then we probably should do it (“it” = be > consistent.) > > Sometimes we want to do things because it makes things clean and pretty. > When that’s the only reason to do something, we should be cautious (it > would be clean and pretty if everybody worked 9-5, and out of an office, > right?). If clean and pretty leads to better data, and that data is > required and used for better decision making, different story. > It is also important for everybody who files a bug in a component handled by a team they are not on. We obviously want people who are not on the, say, graphics team to file graphics bugs. We should have some way to indicate to these bug reporters what sort of priority their bug is being treated as, in a way that they can understand. Teams can spend a little bit of time learning to select "backlog" or whatever instead of "P5", or they can spend time in every bug communicating to reporters what "P5" means to their particular team. The former is more efficient over all. Or we can have the status quo, where bugs that aren't being actively worked on have a status that is just confusing to bug reporters, which discourages people from filing more bugs. Andrew > > — > - Milan > > > > > On Apr 1, 2016, at 11:16 , Andrew McCreight <amccrei...@mozilla.com> > wrote: > > > > On Thu, Mar 31, 2016 at 4:01 PM, Chris Peterson <cpeter...@mozilla.com> > > wrote: > > > >> Anthony's Media Playback team has been using a simple and effective > triage > >> system without special tags. All open bugs in the Audio/Video Playback > >> component are in one of four states at all times: > >> > >> * Priority P1 bugs should be fixed ASAP. > >> * Priority P2 bugs are real bugs or features we want to fix soon. > >> * Priority P5 bugs are "patches accepted" bugs. > >> * Bugs without a priority are untriaged. > >> > > > > The drawback of indicating priorities in this way is that it is totally > > opaque to anybody who is not on that particular subteam, let alone > somebody > > who is using Bugzilla for the first time to report breakage on a site > they > > use. If this was marked "backlog" or whatever instead of "P5", and there > > was a link to an explanation of what "backlog" meant, then it would make > it > > much easier for people to figure out what is going on in any bug. I think > > that is a big advantage of the proposed triaging system, even though I > > think it is reasonable for anybody to be skeptical of adding even more > > bells and whistles to the Bugzilla interface. > > > > Andrew > > > > > >> P3 and P4 are not used. :) P5 sends a pretty clear message to people > that > >> we will not fix that issue any time soon. However, the P5 list is pretty > >> clean because we aggressively WONTFIX bugs we truly don't want to fix > >> instead of letting them linger. > >> > >> Bugzilla already has a lot of fields. It seems like new workflows could > be > >> built with a streamlined frontend UI without changing Bugzilla's > database > >> schema. The advantage of codifying existing workflows instead of adding > new > >> fields is that existing bugs will be compatible with the new system. > >> > >> IIRC, the Fennec team also tracked the "Someone is working on this" > >> proposed in Emma's plan by assigning owners to all bugs, but developers > >> would change their bug's status from NEW to ASSIGNED only when they > began > >> actively working on the bug. > >> > >> _______________________________________________ > >> 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
