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
