Improving Bugzilla Status Names

[Nate Graham]

+1 from me, needless to say. :)

Nate



On 09/04/2018 08:28 PM, Andrew Crouthamel wrote:
> Hello,
> 
> As part of the "Streamlined onboarding of new contributors" goal from 
> 2017 (https://phabricator.kde.org/T7116), Nate, myself, Julian, and 
> others have been working on ways to clean up Bugzilla, as well as the 
> bug reporting and triaging system in the "Improvements to Bugzilla - 
> Making it easier and simpler" sub-task (https://phabricator.kde.org/T6832).
> 
> The next item on the list we would like to address is changing some of 
> the names of the Status fields and Resolved sub-fields. This is 
> something that has come up numerous times, but seems to fizzle out 
> without a consensus. The last major discussion regarding it was held 
> early in the year, here: 
> https://mail.kde.org/pipermail/kde-community/2018q1/004395.html. And 
> before that, in this Bug report from Nate 
> (https://bugs.kde.org/show_bug.cgi?id=383753). I've read through these, 
> merging the feedback from everyone and with the team working on T6832 
> we'd like to propose the following name changes:
> 
> UNCONFIRMED -> NEW
> WONTFIX -> ASDESIGNED
> INVALID -> NOTABUG
> 
> This would keep the current bug triaging flow, but clarify and soften 
> meanings for bug reporters.
> 
> Example bug flow:
> 1. New bugs would be reported and assigned NEW.
> 2. Bugs are triaged and reviewed.
>      a. If reproducible, bugs are set to CONFIRMED.
>      b. If bug is not reproducible, more information is requested from 
> the reporter and set to NEEDSINFO + WAITINGFORINFO.
>      c. If bug is not a bug, set to RESOLVED + NOTABUG.
>      d. If bug is not fixable due to technical limitations, or expected 
> behavior, set to RESOLVED + ASDESIGNED.
> 3. After a set period of time, say 30 days, NEEDSINFO + WAITINGFORINFO 
> bugs are set to RESOLVED + NOTABUG.
> 
> This would allow triagers to come into a product and understand:
> 1. Which bugs need first review and reproducing, helping developers out 
> by acting as that second-level support. (NEW)
> 2. Which need a second look or closure due to lack of information, 
> reproducibility, and age. (NEEDSINFO + WAITINGFORINFO)
> 3. Which bugs are waiting for developer action such as patch development 
> or decision to support a request, and probably do not need triager 
> action. (CONFIRMED)
> 
> This is a pretty minor change, as all it will do is make some words 
> nicer and clarify the triaging process.
> 
> Hopefully this is agreeable to everyone, we believe it is the best 
> compromise between all of the feedback previously provided in the past 
> two years.
> 
> Feedback? Comments? Consensus?
> 
> Thanks!
> Andrew Crouthamel