Re: Killing off UNCONFIRMED in Bugzilla

[Sébastien Wilmet <swilmet gnome org>]

On Sat, Feb 14, 2015 at 10:12:22PM +0100, Andre Klapper wrote:
> On Sat, 2015-02-14 at 21:27 +0100, Sébastien Wilmet wrote:
> > A bug triager only needs to look at UNCONFIRMED bugs.
>
> I strongly disagree with that statement.
> Triage takes place across the full life cycle of a report [1].

I meant, look at UNCONFIRMED bugs _in priority_, since those were
probably not triaged at all.

> > A contributor willing to fix a bug has more chances to find a real bug
> > with the NEW status.
>
> A new contributor willing to fix a bug might be better off picking a
> gnome-love bug.

And for all other contributors like me? gnome-love is fine for the first
one or two patches. Beyond these, searching the bugs marked as NEW is a
good way to find real bugs that need to be fixed upstream.

> > It's even more important for feature requests. If a contributor provides
> > a patch for an unconfirmed feature request and then the bug is closed as
> > wontfix, I think the contributor won't come back ;-)
>
> So triage incoming bug reports and set proper expectations by setting
> status RESOLVED WONTFIX for such tickets right away, instead of spending
> the approx. same amount of time for changing status UNCONF to NEW?

Ok, but what to do with all the old bugs that are not well triaged?
gedit contains more than 400 bugs, and triaging all of them takes a lot
of time. If one day all of them are well triaged, then yes, it makes
sense to remove the UNCONFIRMED status (but in that case we must be sure
to well triage all new incoming bugs, and history has shown that it's
not always the case).

> > The UNCONFIRMED status can be kept around to not break URLs, but would
> > be hidden by default, no?
>
> Your bookmarked query for open tickets which searches for statuses
> UNCONFIRMED, NEW, ASSIGNED, REOPEN will not magically include those open
> tickets with a newly introduced new status (e.g. CONFIRMED)...

Yeah, right.

Sébastien