Bug 383753 - Consider changing some resolution statuses in bugs.kde.org to avoid making some people feel bad
Summary: Consider changing some resolution statuses in bugs.kde.org to avoid making so...
Status: RESOLVED FIXED
Alias: None
Product: bugs.kde.org
Classification: Websites
Component: general (show other bugs)
Version: unspecified
Platform: Other Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: KDE sysadmins
URL:
Keywords: usability
Depends on:
Blocks:
 
Reported: 2017-08-20 14:12 UTC by Nate Graham
Modified: 2018-09-18 13:37 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nate Graham 2017-08-20 14:12:48 UTC
I've noticed that users on bugs.kde.org whose bugs are closed with the RESOLVED INVALID status sometimes seem to take offense, and occasionally even assume they have been insulted. When closing bugs with this status, I find myself pre-emptively explaining the meaning of the status to avoid offending people by adding something like:

    I'm marking this as RESOLVED INVALID, which just means that it's not our bug.

Similarly, WONTFIX implies that we know it's a bug, but are spitefully refusing to fix it, which is not at all the intention of the status.

We might consider changing INVALID to NOTABUG or NOTOURBUG or something else a little softer, or even adding a HARDWAREISSUE status.

And we might consider changing WONTFIX to ASDESIGNED or INTENTIONAL.
Comment 1 Halla Rempt 2017-08-20 15:38:34 UTC
Yes... I'd also like a TRIAGED_COULD_NOT_CONFIRM or something like that between unconfirmed and confirmed...
Comment 2 Nate Graham 2017-08-20 18:06:09 UTC
Basically I advocate doing the following:

INVALID -> NOTABUG
WONTFIX -> INTENTIONAL or ASDESIGNED or something like that

New status: NOTOURBUG
Comment 3 Christoph Feck 2017-08-30 18:38:03 UTC
> I'm marking this as RESOLVED INVALID, which just means that it's not our bug.

We have UPSTREAM and DOWNSTREAM to indicate that it is not our bug. Do you know of tickets that we need to correct?

> WONTFIX implies that we know it's a bug, but are [...] refusing to fix it

WONTFIX should not be used for bugs. The exception is when WONTFIX is used as in CANNOTFIX (because of requirements or limitations of the underlying components), such as X11 requiring grabs for popups, etc. If a developer is not able to fix a bug, the ticket must remain open. Again, do you know of tickets where a developer used this resolution incorrectly?

For feature request, a developer may decide that the feature should never be added and use the WONTFIX solution. The alternative to marking feature requests as WONTFIX is keeping them open. This is the norm, because a future developer might have a different opinion than the developer who first decided this. If, however, multiple developers raised valid points against a feature, it makes sense to close as WONTFIX. If it was a useful idea, it will be suggested again years later anyway, so a different batch of developers can decide anew.

> I'd also like a TRIAGED_COULD_NOT_CONFIRM

We have keywords, such as "triaged", "investigated", "reproducible", "needs_testcase" and "needs_verification".
Comment 4 Halla Rempt 2017-08-31 07:35:18 UTC
On Wed, 30 Aug 2017, Christoph Feck wrote:

> https://bugs.kde.org/show_bug.cgi?id=383753
> 
> --- Comment #3 from Christoph Feck <cfeck@kde.org> ---
> > I'm marking this as RESOLVED INVALID, which just means that it's not our bug.
> 
> We have UPSTREAM and DOWNSTREAM to indicate that it is not our bug. Do you know
> of tickets that we need to correct?

Here's a bug that I close as invalid:

https://bugs.kde.org/show_bug.cgi?id=384202

> 
> > WONTFIX implies that we know it's a bug, but are [...] refusing to fix it
> 
> WONTFIX should not be used for bugs. The exception is when WONTFIX is used as
> in CANNOTFIX (because of requirements or limitations of the underlying
> components), such as X11 requiring grabs for popups, etc. If a developer is not
> able to fix a bug, the ticket must remain open. Again, do you know of tickets
> where a developer used this resolution incorrectly?

I use wontfix when the report is about something that shouldn't be "fixed" --
the reporter doesn't know how blending mode maths work, for instance, and demands
that the 2 * 2 becomes 3.

> For feature request, a developer may decide that the feature should never be
> added and use the WONTFIX solution. The alternative to marking feature requests
> as WONTFIX is keeping them open. This is the norm, because a future developer
> might have a different opinion than the developer who first decided this. If,
> however, multiple developers raised valid points against a feature, it makes
> sense to close as WONTFIX. If it was a useful idea, it will be suggested again
> years later anyway, so a different batch of developers can decide anew.
> 
> > I'd also like a TRIAGED_COULD_NOT_CONFIRM
> 
> We have keywords, such as "triaged", "investigated", "reproducible",
> "needs_testcase" and "needs_verification".

Yeah, but what resolution belongs to that?
Comment 5 Nate Graham 2017-08-31 15:51:40 UTC
My objection isn't that people are misusing the statuses. It's that several of the statuses themselves don't adequately convey what we think they do, or seem unnecessarily harsh.

For example, you point out that WONTFIX is used for denied feature requests, not bugs. But then the word FIX is inappropriate; you fix bugs, not features. Features are implemented, not fixed. So this should be called WONTIMPLEMENT or WONTDO or something like that. You see, the word WONTFIX *implies* the existence of a bug that we are consciously deciding not to fix. Since that's not accurate, the word isn't expressing to novice bugtracker users what we think it does.

INVALID had a judgmental tone. I think NOTABUG or CANTREPRODUCE are softer and more expressive.

Finally, it RESOLVED DOWNSTREAM appropriate for bugs that turn out to be hardware-related? It's not clear.
Comment 6 Christoph Feck 2017-09-13 01:59:28 UTC
> you fix bugs, not features.

If a feature is added, the ticket is resolved as FIXED, so it is symmetrical to marking a denied feature with WONTFIX. You could demand a new resolution for features, such as IMPLEMENTED, ADDED, or whatever, but any missing feature is someone else's bug.

> NOTABUG or CANTREPRODUCE
> Yeah, but what resolution belongs to that?

We also have WORKSFORME. Any type of closing a bug without a fix looks judgmental to the reporter, because he _has_ the issue, otherwise he would not have reported it. I keep most tickets open in the hope that with more eyes we find someone who understands the issue and can suggest a fix or a workaround, or can explain what the reporter did wrong.

> Here's a bug that I close as invalid:
>
> https://bugs.kde.org/show_bug.cgi?id=384202

Looks okey. I also use NEEDSINFO+WAITINGFORINFO, if I am able to instruct the reporter what information developers could need to understand or further investigate the issue. If I do not get any reply after some 2+2 weeks, I give up and also set RESOLVED+INVALID, see e.g. bug 380361.

I have been chasing bugzilla since nearly 9 years, and the only thing that I would change is merging "UNCONFIRMED" and "CONFIRMED" to a single state "OPEN". The distiction has cost us many man hours explaining that there is no difference to most developers.
Comment 7 Nate Graham 2018-09-18 13:37:36 UTC
This was done recently:

UNCONFIRMED -> REPORTED
INVALID -> NOT A BUG
WONTFIX -> INTENTIONAL