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. > 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)... Cheers, andre [1] See e.g. section "Question Time" on page 6 of http://thomas-zimmermann.com/publications/files/breu-cscw-2010.pdf -- Andre Klapper | ak...@gmx.net http://blogs.gnome.org/aklapper/ _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list