Improving Bugzilla Status Names

[Andrew Crouthamel]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20180905/042256a3/attachment.htm>