Re: Attempt to Triage Bug 329386

[Elijah Newren <newren gmail com>]

On 2/11/06, Lex Hider <lexhider internode on net> wrote:
> Hi,
> Can you explain why you think the unconfirmed vs new change is useless?

Sure.

> Whenever I am triaging bugs I take unconfirmed to mean that no one has
> looked at it, and new to mean that it has been looked at is on a todo
> list.

Certainly, but here's your fair warning that I'm kinda verbose.  ;-)

You made a perfectly reasonable guess at what unconfirmed vs. new
_should_ mean.  It still leaves open questions of meaning in regards
to who has looked at it and whose todo list it is on.  It also brings
up questions of who are we trying to make it useful for -- reporters
or developers[1]?

However, the simple fact of the matter is that unconfirmed vs. new
doesn't mean anything remotely close to that in bugzilla right now. 
It would take a huge bugsquad effort (and this has been attempted many
times) to try to get things into such a state.  But things would fall
apart again because we don't have all the needed infrastructure there
yet (though we are moving towards such a point; bkor has added some
things to make this better) to go with the effort.

Because it's not in such a state:
  - as a developer, I have to watch all bugs, both new and unconfirmed
  - I can't search on new bugs or unconfirmed bugs and expect to be
able to make any useful assumptions on the types of bugs I'll get back
  - I get spammed with absolutely zero benefit if a bug is changed
from unconfirmed to new with no other changes; while one email that
has to be read to determine if something changed or new info was added
and finding it was a waste of my time doesn't hurt much at all when
it's only one email, it adds up really quickly as it compounds over
tons of emails.

> I think being the reporter of a bug that remains unconfirmed is
> especially frustrating as you're not sure if anyone has even looked at
> your bug let alone working on it.

Yes, and I'm sure that's why others like doing the unconfirmed->new
and is the reason that I haven't officially proposed that we just stop
doing this.  But I don't think it helps bugs actually get fixed, that
if the developer doesn't have time to look at it anyway that having a
bugsquadder mark it as confirmed isn't going to soothe the reporter
that much, and that it's actually doing more harm than good.

Of course, this is just my opinion, and I do think I'm in the
minority.  But you did ask.

Cheers,
Elijah


[1] It could be targetted to try to make it useful for both, but let's
look deeper at the developer side of the coin.  Should developers need
to look at unconfirmed bugs, or should unconfirmed be a holding stage
where bugsquadders can first check for dupes or request more
information before marking as new and then developers see it?  We
could only do this if the bugsquad could reliably and quickly move
such bugs to a new state, and maintainers may want to be able to see
unconfirmed bugs in their product anyway if they have one with smaller
bugs than others have.  This would be really cool because it'd
strongly cut down on the number of emails & bugs that developers
needed to worry about (and it's effectively an alternate way of doing
some other stuff I recently suggested in regards to anonymous
submissions), but we definitely don't have the infrastructure there
right now.