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