Let's get rid of UNCONFIRMED/CONFIRMED

Boudewijn Rempt boud at valdyas.org
Tue Feb 27 10:41:04 UTC 2018


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.

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

> 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


-- 
Boudewijn Rempt | https://www.valdyas.org | https://www.krita.org





More information about the kde-community mailing list