Improving Bugzilla Status Names

Nate Graham nate at
Wed Sep 5 03:55:18 BST 2018

+1 from me, needless to say. :)


On 09/04/2018 08:28 PM, Andrew Crouthamel wrote:
> Hello,
> As part of the "Streamlined onboarding of new contributors" goal from 
> 2017 (, 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 (
> 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: 
> And 
> before that, in this Bug report from Nate 
> ( 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:
> 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

More information about the kde-community mailing list