Re: Killing off UNCONFIRMED in Bugzilla

On Sat, 2015-02-14 at 22:12 +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].

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. There's a query for them on the product browse page,
sorted by latest update so rotting bug reports are listed last.

IMO, "more chances to find a real bug" only applies in a well-gardened
bug repository where constant triage takes place so all tickets are in
good and up-to-date shape.

Just wanted to point out that most projects which use gnome bugzilla
are relatively small and have bug counts in the mere hundreds, with
the exception of a few central products like GTK+.

To be frank, with bug counts numbering 3 or 4 hundred, I have only
ever had use for UNCONFIRMED and RESOLVED.

However I could see that with a product like mozilla or libreoffice,
it totally makes sense to have triaging and confirmed status and the

That said, I honestly dont care if NEW becomes the new UNCONFIRMED so
long as little to no damage is caused by this.

It certainly wont magickly cause maintainers of said modules to have
more time to deal with bugs - if some people feel that "UNCONFIRMED" is
a rude way to express the "NOT RESOLVED" status, and would prefer to
call it "NEW", then that, in itself doesnt bother me at all :)


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?

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


[1] See e.g. section "Question Time" on page 6 of

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]