Re: Killing off UNCONFIRMED in Bugzilla
On Sun, Feb 15, 2015 at 11:07:50AM +0100, Sébastien Wilmet wrote: 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. Also, there is a difference between the daily triaging, i.e. answering in bugzilla after receiving a mail notification; and triaging old bugs by looking directly in bugzilla. For the latter, I look first at UNCONFIRMED bugs. And for the former, do we really call that triaging? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Killing off UNCONFIRMED in Bugzilla
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 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Killing off UNCONFIRMED in Bugzilla
On Sun, Feb 15, 2015 at 11:07:50AM +0100, Sébastien Wilmet wrote: On Sat, Feb 14, 2015 at 10:12:22PM +0100, Andre Klapper wrote: 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). 400 bugs is not a huge number to triage. It seems you're talking about multiple things. For triaging bugs, you have to deal with loads of bugs which are in UNCO status, but have been triaged. Meaning: they are real bug but never moved out of UNCO. When looking for bugs to fix, you'll have to look at UNCO as well as NEW. But looking for bugs to fix is not triaging. While triaging it is easier to say that you looked at it vs knowing it really is a bug. Together with the amount of emails being sent I usually leave things as UNCO. Ideally you'd first have everything handled by a triage team, then it goes to a developer. If there's a new developer you'd want to give them a list of bugs. I don't see how UNCO vs NEW in the current usage is beneficial. Practically for most products no distinction is made _at all_. Bugs are randomly spread across both statuses. -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Killing off UNCONFIRMED in Bugzilla
On Fri, Feb 13, 2015 at 04:51:58PM +0100, Olav Vitters wrote: Action required: IF YOU WANT TO KEEP UNCONFIRMED FOR YOUR PRODUCT PLEASE SPEAK UP!! Please keep the UNCONFIRMED status for: gedit gtksourceview latexila ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
