Re: Improving Bugzilla Status Names
On zondag 30 september 2018 18:57:05 CEST Andrew Crouthamel wrote: > Yeah I never really understood the purpose of that. Just set it to reported > status then or confirmed. Whatever it was before. I hate reopened myself... I feel it shouts "you failed to fix it properly!" at me :-) -- https://www.krita.org signature.asc Description: This is a digitally signed message part.
Re: Improving Bugzilla Status Names
Yeah I never really understood the purpose of that. Just set it to reported status then or confirmed. Whatever it was before. Original Message On Sep 30, 2018, 12:42 PM, Nate Graham wrote: > On 09/30/2018 10:39 AM, David Jarvie wrote: >> I think that REPORTED is an ideal term for a newly opened bug. Is there >> really a problem with the abbreviations REPO and REOP? Surely people >> will quickly get used to making the distinction, if they make a mistake >> at all. In any case, as soon as the bug report is accessed, it will be >> clear what its status is. Please keep REPORTED and REOPENED as they are. > > Devil's advocate position: do we even need REOPENED? Does it add any > value to have a status that just means, "REPORTED, but also this was > previously closed"? > > Nate
Re: Improving Bugzilla Status Names
On 09/30/2018 10:39 AM, David Jarvie wrote: I think that REPORTED is an ideal term for a newly opened bug. Is there really a problem with the abbreviations REPO and REOP? Surely people will quickly get used to making the distinction, if they make a mistake at all. In any case, as soon as the bug report is accessed, it will be clear what its status is. Please keep REPORTED and REOPENED as they are. Devil's advocate position: do we even need REOPENED? Does it add any value to have a status that just means, "REPORTED, but also this was previously closed"? Nate
Re: Improving Bugzilla Status Names
On 28 September 2018 09:48:42 BST, Luigi Toscano wrote: >Kai Uwe Broulik ha scritto: >> Hi, >> >> > Here is my follow-up change recommendation based on feedback and >research: >> > >> > UNCONFIRMED -> REPORTED >> > WONTFIX -> INTENTIONAL >> > INVALID -> NOTABUG >> >> one issue I'm having with "REPORTED" is that it shows up as "REPO" in >the list >> and can easily be confused with "REOP" for "REOPENED". Perhaps we >need >> something different for Reopened then. > >If we rename also that, we would have two bug names diverging from the >other >bug trackers, instead of just one. Moreover I find that there is no >much to >discuss on the appropriateness of REOPENED. >I'd rather find an alternative for REPORTED, if this confusion is going >to be >an issue. > >-- >Luigi I think that REPORTED is an ideal term for a newly opened bug. Is there really a problem with the abbreviations REPO and REOP? Surely people will quickly get used to making the distinction, if they make a mistake at all. In any case, as soon as the bug report is accessed, it will be clear what its status is. Please keep REPORTED and REOPENED as they are. -- David Jarvie KAlarm author, KDE developer http://www.astrojar.org.uk/kalarm
Re: Improving Bugzilla Status Names
I like OPENED as well. Original Message On Sep 29, 2018, 6:17 PM, Ben Cooksley wrote: > On Sun, Sep 30, 2018 at 9:44 AM Valorie Zimmerman > wrote: >> >> On Fri, Sep 28, 2018 at 1:48 AM Luigi Toscano >> wrote: >>> >>> Kai Uwe Broulik ha scritto: >>> > Hi, >>> > >>> > > Here is my follow-up change recommendation based on feedback and >>> > > research: >>> > > >>> > > UNCONFIRMED -> REPORTED >>> > > WONTFIX -> INTENTIONAL >>> > > INVALID -> NOTABUG >>> > >>> > one issue I'm having with "REPORTED" is that it shows up as "REPO" in the >>> > list >>> > and can easily be confused with "REOP" for "REOPENED". Perhaps we need >>> > something different for Reopened then. >>> >>> If we rename also that, we would have two bug names diverging from the other >>> bug trackers, instead of just one. Moreover I find that there is no much to >>> discuss on the appropriateness of REOPENED. >>> I'd rather find an alternative for REPORTED, if this confusion is going to >>> be >>> an issue. >>> >>> -- >>> Luigi >> >> >> OPENED ? > > Definitionally reported is definitely the right word to be using, but > given that conflict/simiilarity between REPO/REOP I think opened is > probably the best term we can get here. > None of the synonyms for reported fit that's for sure. > >> >> Valorie >> -- >> http://about.me/valoriez >> >> > > Cheers, > Ben
Re: Improving Bugzilla Status Names
On domenica 23 settembre 2018 22:09:02 CEST, Nate Graham wrote:
On 09/23/2018 03:40 AM, Elvis Angelaccio wrote:
On sabato 22 settembre 2018 17:31:31 CEST, Nate Graham wrote:
e.g. RESOLVED WONTFIX and RESOLVED INTENTIONAL both mean the
same thing ("We won't be implementing this").
I'm not sure how "intentional" mean the same thing as "will not fix".
RESOLVED WONTFIX begs the question: "why won't you fix it"?
Also, some users would mentally add "are you lazy? do you hate
me?" and become offended.
Those people now will probably switch to "why are you intentionally leaving
it broken?"
People who like to complain about bugs in open source software will
continue
to do so, no matter the label we use to close their reports.
Cheers,
Elvis
Re: Improving Bugzilla Status Names
On 2018-09-29, Valorie Zimmerman wrote: >> discuss on the appropriateness of REOPENED. >> I'd rather find an alternative for REPORTED, if this confusion is going to >> > > OPENED ? RECIEVED ? though opened might be better. /Sune
Re: Improving Bugzilla Status Names
On Sun, Sep 30, 2018 at 9:44 AM Valorie Zimmerman wrote: > > On Fri, Sep 28, 2018 at 1:48 AM Luigi Toscano > wrote: >> >> Kai Uwe Broulik ha scritto: >> > Hi, >> > >> > > Here is my follow-up change recommendation based on feedback and >> > research: >> > > >> > > UNCONFIRMED -> REPORTED >> > > WONTFIX -> INTENTIONAL >> > > INVALID -> NOTABUG >> > >> > one issue I'm having with "REPORTED" is that it shows up as "REPO" in the >> > list >> > and can easily be confused with "REOP" for "REOPENED". Perhaps we need >> > something different for Reopened then. >> >> If we rename also that, we would have two bug names diverging from the other >> bug trackers, instead of just one. Moreover I find that there is no much to >> discuss on the appropriateness of REOPENED. >> I'd rather find an alternative for REPORTED, if this confusion is going to be >> an issue. >> >> -- >> Luigi > > > OPENED ? Definitionally reported is definitely the right word to be using, but given that conflict/simiilarity between REPO/REOP I think opened is probably the best term we can get here. None of the synonyms for reported fit that's for sure. > > Valorie > -- > http://about.me/valoriez > > Cheers, Ben
Re: Improving Bugzilla Status Names
On Fri, Sep 28, 2018 at 1:48 AM Luigi Toscano wrote: > Kai Uwe Broulik ha scritto: > > Hi, > > > > > Here is my follow-up change recommendation based on feedback and > research: > > > > > > UNCONFIRMED -> REPORTED > > > WONTFIX -> INTENTIONAL > > > INVALID -> NOTABUG > > > > one issue I'm having with "REPORTED" is that it shows up as "REPO" in > the list > > and can easily be confused with "REOP" for "REOPENED". Perhaps we need > > something different for Reopened then. > > If we rename also that, we would have two bug names diverging from the > other > bug trackers, instead of just one. Moreover I find that there is no much > to > discuss on the appropriateness of REOPENED. > I'd rather find an alternative for REPORTED, if this confusion is going to > be > an issue. > > -- > Luigi > OPENED ? Valorie -- http://about.me/valoriez
Re: Improving Bugzilla Status Names
Kai Uwe Broulik ha scritto: Hi, > Here is my follow-up change recommendation based on feedback and research: > > UNCONFIRMED -> REPORTED > WONTFIX -> INTENTIONAL > INVALID -> NOTABUG one issue I'm having with "REPORTED" is that it shows up as "REPO" in the list and can easily be confused with "REOP" for "REOPENED". Perhaps we need something different for Reopened then. If we rename also that, we would have two bug names diverging from the other bug trackers, instead of just one. Moreover I find that there is no much to discuss on the appropriateness of REOPENED. I'd rather find an alternative for REPORTED, if this confusion is going to be an issue. -- Luigi
Re: Improving Bugzilla Status Names
Hi, > Here is my follow-up change recommendation based on feedback and research: > > UNCONFIRMED -> REPORTED > WONTFIX -> INTENTIONAL > INVALID -> NOTABUG one issue I'm having with "REPORTED" is that it shows up as "REPO" in the list and can easily be confused with "REOP" for "REOPENED". Perhaps we need something different for Reopened then. Cheers Kai Uwe
Re: Improving Bugzilla Status Names
Nate Graham ha scritto:
On 09/23/2018 03:40 AM, Elvis Angelaccio wrote:
On sabato 22 settembre 2018 17:31:31 CEST, Nate Graham wrote:
e.g. RESOLVED WONTFIX and RESOLVED INTENTIONAL both mean the same thing
("We won't be implementing this").
I'm not sure how "intentional" mean the same thing as "will not fix".
RESOLVED WONTFIX begs the question: "why won't you fix it"? Also, some users
would mentally add "are you lazy? do you hate me?" and become offended.
I'm sure that some users will challenge the reason of INTENTIONAL ("are you
nut? This is not how it should work").
Regardless of the reason, a status is just the most concise summary. For any
closing states, the developer should write down the reason in the last
comment, so that users can check the explanation for it (and make a WONTFIX
not scary, like any other final status).
There are a few reasons why a bug would previously have been closed as
RESOLVED WONTFIX:
- Because the software has been designed this way on purpose, so a change is
undesirable: REVOLVED INTENTIONAL covers this
- Because it is technically impossible to fix: essentially the same thing;
software was designed in that way, so RESOLVED INTENTIONAL is still appropriate
So those have the same meaning.
- Because the developer just doesn't feel like doing the work: not a valid
reason to close a bug; bug should stay open
- Because the developer wishes to spitefully punish the bug reporter for
behaving badly in the ticket, and in the process hurts all KDE users who could
benefit from a better resolution: not a valid reason to close a bug; bug
should stay open
I think that in both cases the RESOLVED WONTFIX should not be used, and at the
same time nothing prevents developers to use it just because it's called
INTENTIONAL, which means a complete equivalence of the two states.
If the reason for this change is prevent the 4th case, I'm not sure it's going
to help.
So I think REVOLVED INTENTIONAL covers all of the valid reasons to close a bug
report that the developers will not or cannot fix.
At least, that's what makes sense to me.
I'm not specifically attached to this change, so *I'm fine with keeping it as
it is.*
I would point out that the similar "Opinion" status on launchpad has been
challenged:
https://help.launchpad.net/Bugs/Statuses
https://bugs.launchpad.net/launchpad/+bug/772954
I agree that this entire discussion was rushed out.
--
Luigi
Re: Improving Bugzilla Status Names
On 09/23/2018 03:40 AM, Elvis Angelaccio wrote:
On sabato 22 settembre 2018 17:31:31 CEST, Nate Graham wrote:
e.g. RESOLVED WONTFIX and RESOLVED INTENTIONAL both mean the same
thing ("We won't be implementing this").
I'm not sure how "intentional" mean the same thing as "will not fix".
RESOLVED WONTFIX begs the question: "why won't you fix it"? Also, some
users would mentally add "are you lazy? do you hate me?" and become
offended.
There are a few reasons why a bug would previously have been closed as
RESOLVED WONTFIX:
- Because the software has been designed this way on purpose, so a
change is undesirable: REVOLVED INTENTIONAL covers this
- Because it is technically impossible to fix: essentially the same
thing; software was designed in that way, so RESOLVED INTENTIONAL is
still appropriate
- Because the developer just doesn't feel like doing the work: not a
valid reason to close a bug; bug should stay open
- Because the developer wishes to spitefully punish the bug reporter for
behaving badly in the ticket, and in the process hurts all KDE users who
could benefit from a better resolution: not a valid reason to close a
bug; bug should stay open
So I think REVOLVED INTENTIONAL covers all of the valid reasons to close
a bug report that the developers will not or cannot fix.
At least, that's what makes sense to me.
Nate
Re: Improving Bugzilla Status Names
On sabato 22 settembre 2018 17:31:31 CEST, Nate Graham wrote:
On 09/22/2018 05:41 AM, Elvis Angelaccio wrote:
We are talking about a pretty big change in our workflow
Can you comment on how this has impacted your workflow? For me
it hasn't resulted in any workflow changes at all since the new
strings mean the same thing as the old ones. The point was
simply to soften them a bit.
e.g. RESOLVED WONTFIX and RESOLVED INTENTIONAL both mean the
same thing ("We won't be implementing this").
I'm not sure how "intentional" mean the same thing as "will not fix".
However, because
feature requests get implemented and not fixed, the presence of
the word "fix" in the phase WONTFIX implied that there is a bug
that we are ignoring for some reason, which was obviously not
true.
That's all true, but... that's just how bugzilla works.
In fact, if we do implement the wishlist, we close the ticket as FIXED. :D
Nate
Cheers,
Elvis
Re: Improving Bugzilla Status Names
On sabato 22 settembre 2018 14:35:21 CEST, Boudewijn Rempt wrote: On zaterdag 22 september 2018 13:41:39 CEST Elvis Angelaccio wrote: I'm surprised the new names have already been deployed on bugzilla. We are talking about a pretty big change in our workflow and I think we didn't discuss it enough. Also, many developers are not on this list and we should have contacted at least kde-devel first. I disagree. If you're part of the KDE community, you should be on this list. Right, but that doesn't change the fact that some developers (for whatever reason) are not on this list. And bugzilla is a tool mainly for developers. And it's been discussed on and off for over a year: plenty enough. It took less than a week this time, though. I wanted to join this discussion but I was too late, that's a bit frustrating. For example, I don't understand how am I supposed to close wishlists now. Resolved-Wontix made sense to me, Resolved-Later or Resolved-Intentional do not, imho. In my opinion, resolved/intentional is as appropriate as resolved/wontfix -- since a wish isn't bug, implementing it isn't a fix either. All bugzilla statuses are crutches, that's just something we have to live with. But at least wontfix is used almost everywhere and its meaning is standard (people even use it as a verb!). Cheers, Elvis
Re: Improving Bugzilla Status Names
On 09/22/2018 05:41 AM, Elvis Angelaccio wrote:
We are talking about a pretty big change in our workflow
Can you comment on how this has impacted your workflow? For me it hasn't
resulted in any workflow changes at all since the new strings mean the
same thing as the old ones. The point was simply to soften them a bit.
e.g. RESOLVED WONTFIX and RESOLVED INTENTIONAL both mean the same thing
("We won't be implementing this"). However, because feature requests get
implemented and not fixed, the presence of the word "fix" in the phase
WONTFIX implied that there is a bug that we are ignoring for some
reason, which was obviously not true. The word INTENTIONAL does IMHO a
better job of communicating "this is behaving as we have consciously
designed it so we won't be changing it."
If someone makes a wishlist request that you won't do, I think closing
it as RESOLVED INTENTIONAL is the appropriate course of action just like
the old RESOLVED WONTFIX.
RESOLVED NOTABUG is for tickets that are actually support requests,
complaints, or anything else not appropriate for a bug tracker, just
like the old RESOLVED INVALID.
Nate
Re: Improving Bugzilla Status Names
On zaterdag 22 september 2018 13:41:39 CEST Elvis Angelaccio wrote: > > I'm surprised the new names have already been deployed on bugzilla. > > We are talking about a pretty big change in our workflow and I think we > didn't discuss it enough. Also, many developers are not on this list and we > should have contacted at least kde-devel first. I disagree. If you're part of the KDE community, you should be on this list. And it's been discussed on and off for over a year: plenty enough. > For example, I don't understand how am I supposed to close wishlists now. > Resolved-Wontix made sense to me, Resolved-Later or Resolved-Intentional do > not, imho. In my opinion, resolved/intentional is as appropriate as resolved/wontfix -- since a wish isn't bug, implementing it isn't a fix either. All bugzilla statuses are crutches, that's just something we have to live with. -- https://www.krita.org signature.asc Description: This is a digitally signed message part.
Re: Improving Bugzilla Status Names
On venerdì 7 settembre 2018 01:43:46 CEST, Andrew Crouthamel wrote: I spent some time looking through RESOLVED > INVALID bugs to see how they are being used. The vast majority are for closing bug reports that were upstream/downstream, no response from reporter, or not a bug to begin with. It appears renaming INVALID to NOTABUG would be a good change, as some of the other bugs that have been closed as RESOLVED > INVALID would be better served under RESOLVED > WORKSFORME (bug report with no response from reporter) or RESOLVED > UPSTREAM (bug report with problematic Nvidia drivers) or RESOLVED > DOWNSTREAM (bug report with distro problems). Regarding closing wishlist items with, I believe RESOLVED > LATER is a good choice, it appears others are already doing that. Here is my follow-up change recommendation based on feedback and research: UNCONFIRMED -> REPORTED WONTFIX -> INTENTIONAL INVALID -> NOTABUG Hi I'm surprised the new names have already been deployed on bugzilla. We are talking about a pretty big change in our workflow and I think we didn't discuss it enough. Also, many developers are not on this list and we should have contacted at least kde-devel first. For example, I don't understand how am I supposed to close wishlists now. Resolved-Wontix made sense to me, Resolved-Later or Resolved-Intentional do not, imho. Cheers, Elvis
Re: Improving Bugzilla Status Names
I spent some time looking through RESOLVED > INVALID bugs to see how they are being used. The vast majority are for closing bug reports that were upstream/downstream, no response from reporter, or not a bug to begin with. It appears renaming INVALID to NOTABUG would be a good change, as some of the other bugs that have been closed as RESOLVED > INVALID would be better served under RESOLVED > WORKSFORME (bug report with no response from reporter) or RESOLVED > UPSTREAM (bug report with problematic Nvidia drivers) or RESOLVED > DOWNSTREAM (bug report with distro problems). Regarding closing wishlist items with, I believe RESOLVED > LATER is a good choice, it appears others are already doing that. Here is my follow-up change recommendation based on feedback and research: UNCONFIRMED -> REPORTED WONTFIX -> INTENTIONAL INVALID -> NOTABUG Andrew Crouthamel ‐‐‐ Original Message ‐‐‐ On 6 September 2018 1:57 PM, Karl Ove Hufthammer wrote: > Andrew Crouthamel skreiv 05. sep. 2018 23:49: > > > Does anyone else have comments on status names? The name itself or yay/nay > > on renames? > > Here are some updated proposed names based on feedback and thesaurus > > searching: > > UNCONFIRMED -> REPORTED or OPEN > > WONTFIX -> ASDESIGNED or INTENTIONAL > > INVALID -> NOTABUG or ERRONEOUS > > I like REPORTED and INTENTIONAL. And if underscores are allowed, I would > prefer them, e.g. NOT_A_BUG. > > > > Karl Ove Hufthammer
Re: Improving Bugzilla Status Names
Andrew Crouthamel skreiv 05. sep. 2018 23:49: Does anyone else have comments on status names? The name itself or yay/nay on renames? Here are some updated proposed names based on feedback and thesaurus searching: UNCONFIRMED -> REPORTED or OPEN WONTFIX -> ASDESIGNED or INTENTIONAL INVALID -> NOTABUG or ERRONEOUS I like REPORTED and INTENTIONAL. And if underscores are allowed, I would prefer them, e.g. NOT_A_BUG. -- Karl Ove Hufthammer
Re: Improving Bugzilla Status Names
Does anyone else have comments on status names? The name itself or yay/nay on renames? Here are some updated proposed names based on feedback and thesaurus searching: UNCONFIRMED -> REPORTED or OPEN WONTFIX -> ASDESIGNED or INTENTIONAL INVALID -> NOTABUG or ERRONEOUS Andrew Crouthamel ‐‐‐ Original Message ‐‐‐ On 5 September 2018 4:36 AM, Christian Loosli wrote: > Am Mittwoch, 5. September 2018, 04:28:05 CEST schrieb Andrew Crouthamel: > > > Hello, > > Hi, > > thanks for your work and looking at this, I agree with them except > > > WONTFIX -> ASDESIGNED > > INVALID -> NOTABUG > > which make it, in my opinion, less clear. > > WONTFIX is not only used when something is "as per design", but also in cases > such as product no longer supported, a third party thing used (e.g. an > interface) doesn't allow it etc. > So "ASDESIGNED" is less clear / sometimes just wrong. I also don't think that > the language needs softening up, because the end result will be the same: the > user who reported the bug or wish does not get what they wanted, so it should > be clear and match what the user will get. > > NOTABUG fails for similar reasons. Bugzilla is also used for feature requests > / wish lists. These aren't bugs by definition, but they can be valid. Also > bugs > can be bugs but still the report can be invalid for other reasons. > > In both cases I think the important thing is that whoever sets this status > should write in the comment why something won't be fixed or why something is > invalid. The status is meant to be short and clear, in the proposals I think > that clarety is removed a bit. > > Rest sounds good to me. > > > Thanks! > > Andrew Crouthamel > > Kind regards, > > Christian
Re: Improving Bugzilla Status Names
Am Mittwoch, 5. September 2018, 11:36:45 CEST schrieb Martin Steigerwald: > Isn´t there RESOLVED / UNMAINTAINED, when product is no longer > supported? It has, leaves us with the other cases. Christian
Re: Improving Bugzilla Status Names
Sorry, I don't have better suggestions. Naming things is a hard problem in bug science. Ilmari Andrew Crouthamel kirjoitti 5.9.2018 klo 11.17: I like REPORTED as well. That leaves timeframe out of the status name. Bugs can stay REPORTED but never CONFIRMED, and that all makes sense. Based on David's feedback, this would work for his needs I believe. As for WONTFIX vs. ASDESIGNED, Ilmari, do you have any suggestions for alternatives? I know that isn't perfect, but was the best we could come up with so far. Andrew Crouthamel Original Message On Sep 5, 2018, 12:03 AM, Nate Graham < n...@kde.org> wrote: On 09/04/2018 10:01 PM, Christoph Feck wrote: > I still oppose to name a status NEW (again). It only attracts "how is > this NEW? this is already [random timespan here] OLD!" comments. > There will always be products/components that have no active maintainer > to look for bugs in a limited timeframe. > > My suggestions are OPEN, REPORTED, or UNRESOLVED. I could get behind OPEN or REPORTED. Nate
Re: Improving Bugzilla Status Names
Christian Loosli - 05.09.18, 10:36: > > WONTFIX -> ASDESIGNED > > INVALID -> NOTABUG > > which make it, in my opinion, less clear. > > WONTFIX is not only used when something is "as per design", but also > in cases such as product no longer supported, a third party thing > used (e.g. an interface) doesn't allow it etc. > So "ASDESIGNED" is less clear / sometimes just wrong. I also don't > think that the language needs softening up, because the end result > will be the same: the user who reported the bug or wish does not get > what they wanted, so it should be clear and match what the user will > get. Isn´t there RESOLVED / UNMAINTAINED, when product is no longer supported? Thanks, -- Martin
Re: Improving Bugzilla Status Names
Am Mittwoch, 5. September 2018, 04:28:05 CEST schrieb Andrew Crouthamel: > Hello, Hi, thanks for your work and looking at this, I agree with them except > WONTFIX -> ASDESIGNED > INVALID -> NOTABUG which make it, in my opinion, less clear. WONTFIX is not only used when something is "as per design", but also in cases such as product no longer supported, a third party thing used (e.g. an interface) doesn't allow it etc. So "ASDESIGNED" is less clear / sometimes just wrong. I also don't think that the language needs softening up, because the end result will be the same: the user who reported the bug or wish does not get what they wanted, so it should be clear and match what the user will get. NOTABUG fails for similar reasons. Bugzilla is also used for feature requests / wish lists. These aren't bugs by definition, but they can be valid. Also bugs can be bugs but still the report can be invalid for other reasons. In both cases I think the important thing is that whoever sets this status should write in the comment why something won't be fixed or why something is invalid. The status is meant to be short and clear, in the proposals I think that clarety is removed a bit. Rest sounds good to me. > Thanks! > Andrew Crouthamel Kind regards, Christian
Re: Improving Bugzilla Status Names
I like REPORTED as well. That leaves timeframe out of the status name. Bugs can stay REPORTED but never CONFIRMED, and that all makes sense. Based on David's feedback, this would work for his needs I believe. As for WONTFIX vs. ASDESIGNED, Ilmari, do you have any suggestions for alternatives? I know that isn't perfect, but was the best we could come up with so far. Andrew Crouthamel Original Message On Sep 5, 2018, 12:03 AM, Nate Graham wrote: > On 09/04/2018 10:01 PM, Christoph Feck wrote: >> I still oppose to name a status NEW (again). It only attracts "how is >> this NEW? this is already [random timespan here] OLD!" comments. >> There will always be products/components that have no active maintainer >> to look for bugs in a limited timeframe. >> >> My suggestions are OPEN, REPORTED, or UNRESOLVED. > > I could get behind OPEN or REPORTED. > > Nate
Re: Improving Bugzilla Status Names
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
Re: Improving Bugzilla Status Names
I'm fine with this as well. On woensdag 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 > > 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 signature.asc Description: This is a digitally signed message part.
Re: Improving Bugzilla Status Names
New/confirmed are more about before/after triage than focussing on reproducible or not. Reproducible or not isn't really a particularly useful thing to know from a dev side. I regularly fix things I can't immediately reproduce. If we want that information a flag solves it better. What's important is making it so that if some other dev/triager has already processed a bug and come to a decision about it, that I don't waste my triage time reading it and making sure that if I open a confirmed bug it has all the info I need to start investigating it.
Re: Improving Bugzilla Status Names
Andrew Crouthamel kirjoitti 5.9.2018 klo 5.28: d. If bug is not fixable due to technical limitations, or expected behavior, set to RESOLVED + ASDESIGNED. WONTFIX is also typically used to refuse to implement features that are out of scope or not aligned with a product vision. Just wanted to point out that in these cases ASDESIGNED does soften the message, but does not clarify it :) Ilmari
Re: Improving Bugzilla Status Names
On 09/04/2018 10:01 PM, Christoph Feck wrote: I still oppose to name a status NEW (again). It only attracts "how is this NEW? this is already [random timespan here] OLD!" comments. There will always be products/components that have no active maintainer to look for bugs in a limited timeframe. My suggestions are OPEN, REPORTED, or UNRESOLVED. I could get behind OPEN or REPORTED. Nate
Re: Improving Bugzilla Status Names
On 05.09.2018 04:28, 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 I still oppose to name a status NEW (again). It only attracts "how is this NEW? this is already [random timespan here] OLD!" comments. There will always be products/components that have no active maintainer to look for bugs in a limited timeframe. My suggestions are OPEN, REPORTED, or UNRESOLVED. -- Christoph Feck
Re: Improving Bugzilla Status Names
+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
Improving Bugzilla Status Names
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
