Re: Attempt to Triage Bug 329386

[Lex Hider <lexhider internode on net>]

On Sat, 2006-02-11 at 17:32 -0700, Elijah Newren wrote:
> 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.
> 

That's interesting. How are we moving to "such a point", and what things
has bkor added to "make this better"?
Also, what is the "needed infrastructure" of which you speak.

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

I do think we should make a decision here. If it's not something that is
of any use to someone, remove or change things so it is useful.

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

I think the idea of developers having only to look at confirmed bugs is
definitely attractive, and could perhaps become a goal of the bugsquad.
I do realize that this would be a goal and not something that could
actually be acheived overnight.

It is also reliant on the bugsquad being knowledgeable enough to
distinguish between "real" bugs where the bugs are highly technical.