Bug 383753

Yes... I'd also like a TRIAGED_COULD_NOT_CONFIRM or something like that between unconfirmed and confirmed...

Basically I advocate doing the following:

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

New status: NOTOURBUG

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

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?

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.

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

This was done recently:

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