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