I've responded to a similar comment in the google doc, but I'll repeat it here.
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. If I was to take that approach, I'm concerned about what it would do with historical data. We'd also have the P3, and P4 values hanging round like vestigial limbs. FYI, in FFx related components. --- 460,362 P1 14,304 P2 15,971 P3 37,933 P4 4,204 P5 2,913 The bulk of bugs in FFx related components are P3. -- Emma On Thu, Mar 31, 2016 at 4:01 PM, Chris Peterson <cpeter...@mozilla.com> wrote: > On 3/31/16 3:22 PM, Daniel Veditz wrote: > >> ​We get that now, with no marker at all. The only real difference I see >> with a marker is that people will catch on sooner whereas now it takes a >> while until they realize they are being ignored. They eventually get >> discouraged​ or upset either way. Might even be better with a marker (for >> some people) because at least they have some acknowledgement that someone >> has looked at the bug even if they disagree about the importance. We may >> have misunderstood, and thus mis-triaged, the bug and an explicit marker >> might trigger the attempt to clarify sooner. >> > > 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. > > 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
