On onsdag 5. september 2018 04.28.05 CEST 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

Does bugzilla allow you to have underscores? I first thought ASDESIGNED is a 
typo. AS_DESIGNED and NOT_A_BUG reads a lot better in my opinion.

I don't have an opinion on the actual content of this otherwise.

Cheers,
Frederik



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