Let's get rid of UNCONFIRMED/CONFIRMED

Elvis Angelaccio elvis.angelaccio at kde.org
Tue Feb 27 19:33:37 GMT 2018


On martedì 27 febbraio 2018 11:41:04 CET, Boudewijn Rempt wrote:
> On Tuesday, 27 February 2018 11:32:10 CET Elvis Angelaccio wrote:
>> Hi,
>> recently we introduced a policy change in bugzilla and now every user has
>> the power to change the status of any ticket.
>> 
>> This is good (and consistent with phabricator) but there is a 
>> big downside:
>> many people will open a new ticket and then mark it as CONFIRMED. This is
>> annoying because now I get two mails instead of one.
>
> Bah, is that really important? It's more annoying if people 
> keep resetting the 
> status because they don't want to accept the developer's resolution.

Sure, that's also a problem we should probably fix.

>
>> There was already a proposal [1] to remove UNCONFIRMED and use 
>> NEW instead.
>> I think now it's a good time to discuss it again.
>
> As I've said a bunch of times, what I need is the following stages:
>
> * bug has been reported, but nobody has looked at it yet
> * bug has been looked at, but could not be reproduced, yet is clearly not 
> worksforme
> * bug has been triaged and can be reproduced.
>
> I don't care what those stages are called (NEW, UNCONFIRMED, 
> CONFIRMED would 
> do fine for me), but using the triaged keyword like I'm trying 
> to do now just 
> doesn't work because it's not a stage in the status flow of a bug report.
>
> I triage over 1000 bugs a year, and resolve about 700 to 800, 
> and not having 
> these stages really hampers my workflow.
>
>> The UNCONFIRMED/CONFIRMED thing has little meaning, is confusing for users
>> and for new triagers and we know that many developers never 
>> set this state.
>
> Given that bugzilla is a tool for developers, I don't care that users might 
> get confused.

It's confusing also for new developers/triagers. Yesterday a new triager 
asked me why I had not set a reproducible bug as confirmed and when he 
should set the confirmed status. It's just an unnecessary step which makes 
the workflow harder than it could be.

>
>> We don't have this problem with phabricator tasks because they can be
>> either Open or closed (for whatever reason).
>
> I don't let users report issues in phabricator anyway, because 
> phabricator is 
> where we plan our work. Bugzilla is the big pile of shit that 
> comes from the 
> outer world. So, phabricator's lack of fine-grained task statuses is 
> irrelevant.
>
>> 
>> Let's make bugzilla consistent with this workflow, if possible.
>> 
>> Discuss!
>> 
>> [1]: https://mail.kde.org/pipermail/kde-community/2016q4/003262.html
>> 
>> Cheers,
>> Elvis
>
>




More information about the kde-community mailing list