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

Reply via email to