Closed Bug 522873 Opened 15 years ago Closed 4 years ago

BMO: change WONTFIX resolution into a value pair (like DUPLICATE of XX), with new sub-values, e.g. "has addon/extension", "addon wanted", "rejected"

Categories

(bugzilla.mozilla.org :: Administration, enhancement, P3)

enhancement

Tracking

()

RESOLVED WONTFIX

People

(Reporter: thomas8, Assigned: emceeaich)

References

Details

We often have bugs coming up with good ideas, but we think it's something that should go into an extension, not the core. Or maybe such an extension already exists. In both cases, unless we want to leave the bug unconfirmed, we can only use a plain "wontfix", which is not very nice for good ideas.

A better indication that a bug contains a valid idea, however we wouldn't want to include it at this time, would be two new status values:

Resolved wontfix, has extension
Resolved wontfix, needs extension

An example for "wontfix, needs extension" would be bug 491368 (Implement warning when sending msgs to certain recipients)
We're not going to add status resolutions that can just be summarized as bug comments or status whiteboard entries explaining the issue. This would just cause UI bloat.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
Status: RESOLVED → VERIFIED
(In reply to comment #1)
> We're not going to add status resolutions that can just be summarized as bug
> comments or status whiteboard entries explaining the issue. This would just
> cause UI bloat.

Thanks for the appreciation that's in the tone of this comment, and sorry for trying to improve the product! In fact, Reed demonstrates how to create the very feeling and the problem I was trying to alleviate with this RFE: Just throw a blunt WONTFIX at an interesting and well-meant idea, and it'll vanish without trace within millions of resolved bugs.

> We're not going to add status resolutions that can just be summarized as bug
> comments or status whiteboard entries explaining the issue.

Yes, that's possible, but we're loosing valuable information on the way:
- freestyle comment XX somewhere at the end of the bug is near impossible to search for
- freestyle whiteboard entries cannot be systematically searched for to find bugs with valid ideas that have or need an extension

> This would just cause UI bloat.

Agreed, my mistake. I didn't explain my idea well enough.
Reed, I was thinking more of a value pair like we currently have for duplicate bugs:
- After resolving DUPLICATE, a new box appears where you can enter the bug number.
- Same here: After resolving WONTFIX, another dropdown box could appear to fine-tune the resolution:

Status: [Resolved v] [WONTFIX v] [---           v]
                                 |has extension  |
                                 |needs extension|

That way, we don't change or clutter the main resolutions, while preserving valuable information about the reasons for wontfix in a systematic manner that can be searched for.

The main problem of a plain "WONTFIX" without extra information is that unless you dig yourself into the bug with all its information, there's no way of telling apart good ideas vs. bad ideas.

Another example:  Bug 304697 -  Make attachment pane movable / dockable
It's a nice idea, but we'll never have the time to do it because there's more urgent priorities. Just marking it WONTFIX will make that idea disappear for good. With "WONTFIX" + "needs extension", someone else could find it and maybe he feels like doing the extension. Plus, we're being more appreciative about useful ideas.

I'll reopen this RFE so that the new proposal described in this comment can be evaluated - no offence meant.
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
Summary: bmo should introduce two new status values: wontfix-has_extension, wontfix-needs_extension → BMO: change WONTFIX resolution into a value pair (like DUPLICATE of XX), with new sub-values: "has extension", "needs extension"
Summary: BMO: change WONTFIX resolution into a value pair (like DUPLICATE of XX), with new sub-values: "has extension", "needs extension" → BMO: change WONTFIX resolution into a value pair (like DUPLICATE of XX), with optional new sub-values: "has extension", "needs extension"
bad ideas are INVALID.

You can't decide if a bug is worth touching without reading it.

a resolution is a status, and statuses are supposed to be used for quick sorting. if you're looking to decide what interesting things there are to do, then a status is not for you. you should pick things by their summary, which will by definition be much more free-form.

AS an example. this component 'bugzilla keywords and components' is for things relating to keywords and components. the resolution field is neither a keyword nor a component. As such, your bug is INVALID.

If you want to discuss this further, please use a newsgroup. thanks for your interest.
Status: REOPENED → RESOLVED
Closed: 15 years ago14 years ago
Resolution: --- → INVALID
Summary: BMO: change WONTFIX resolution into a value pair (like DUPLICATE of XX), with optional new sub-values: "has extension", "needs extension" → BMO: change WONTFIX resolution into a value pair (like DUPLICATE of XX), with new sub-values: "has extension", "needs extension"
(In reply to comment #3)
> bad ideas are INVALID.

Again, that sounds quite unfriendly given the fact that I'm investing my time to try and help with your product. After hundreds of qualified postings and acknowledged successful participation in mozilla's bug triaging effort (find my name in TB 3's shorter list of "Credits"), I probably have some knowledge of what I'm talking about.

> You can't decide if a bug is worth touching without reading it.

True. And I can't decide if a bug is worth touching if I can't even find it because it's buried between hundreds of "wonfixed" bugs that look alike but are in fact different in their status, as I'll show below.
 
> a resolution is a status, and statuses are supposed to be used for quick
> sorting.

Exactly. I'm requesting an option that allows quick sorting / filtering for bugs that have been resolved "wontfix", but developers would still like an addon, or even integrate it into the core if someone else comes up with code.
In other words, it's about distinguishing the following resolutions:
- wontfix in the sense of "we don't ever want this, it's a bad idea"
- wontfix in the sense of "we want this, but we won't/can't do it ourselves. We'd gladly take an addon, though"
- wontfix in the sense of "we like this, but there's an existing addon and we think that's enough."

> if you're looking to decide what interesting things there are to do,
> then a status is not for you. you should pick things by their summary, which
> will by definition be much more free-form.

The summary doesn't tell me anything about the reasons for the wontfix resolution. Yes, I can read the whole bug to find out why it was rejected. Alternatively (as proposed here), it would be much easier (and friendlier towards the reporter) if there was a more qualified (more precise) wontfix resolution at the top of the bug.

As an example, take bug 160261, where dozens of users requested inbuilt tiff support for the browser. After an endless discussion, it was wontfixed. But why? It's very difficult to find out whether this was "wontfix_bad-idea" or "wontfix_needs-addon". If you look at the last comments (bug 160261 comment 40 and 41), you'd think it's a bad idea. But Bug 160261, comment 39 reveals developers actually propose doing this as an addon. The expanded wontfix resolution I propose here would make it much easier and clearer, and more inviting for potential addon-programmers.

> AS an example. this component 'bugzilla keywords and components' is for things
> relating to keywords and components. the resolution field is neither a keyword
> nor a component. As such, your bug is INVALID.

A more cooperative way of handling this minor formal problem might have been to change the component so that it's right. What's the appropriate component, then?

I'll accept that you don't want the change proposed here (which is the "wontfix_bad-idea" type of wontfix), although I'd think it's fair to ensure that the idea is fully understood before it's rejected.

> If you want to discuss this further, please use a newsgroup. thanks for your
> interest.

Unfortunately I'm not into newsgroups, and I believe it's ok to file a concise and specific request for enhancement. Furthermore, I'd think it's ok to discuss things in an enhancement request of which I myself am the reporter. Finally, with only 4 comments so far, I don't think this is getting out of hands yet.
Have a nice day.
Please note:
1) Implementing this bug is fully in line with / supportive of Mozilla's drive towards addon-based application development
2) Implementing this bug will make it a lot easier to resolve bugs "wontfix" while avoiding user protest, i.e. we will increase user acceptance of wontfix decisions
3) specifying the secondary wontfix value could be optional (no changes for those who want to live without)

I'll build a list of bugs that support/illustrate the point of this bug:

Bug 577944 - (wontfix+addonwanted) Bugs that have been or should be resolved WONTFIX, but would make a nice addon
Summary: BMO: change WONTFIX resolution into a value pair (like DUPLICATE of XX), with new sub-values: "has extension", "needs extension" → BMO: change WONTFIX resolution into a value pair (like DUPLICATE of XX), with new sub-values, e.g. "has addon/extension", "addon wanted", "rejected"
Component: Bugzilla: Keywords & Components → Administration
Product: mozilla.org → bugzilla.mozilla.org
There are additional "qualifiers" that could be helpful for wontfixing:
-issue of very low priority (unimportant)
-easy hack

I reported such an issue (Bug 700182). I understand that it really rarely happens; and that it possibly won't hurt too much so that it will not repel users from your product. But it is still an issue, and it is not suitable for an extension (because one uses extensions for (a) known things - this will be unknown for a user until it hits; (b) for things they use often - this will not happen often; and (c) an extension would use awful lot of system resources just for almost nothing). Besides, it should be extremely easy to fix.

Yes, cluttering your workspace with such unimportant issues is bad, so a resolution should move it away from your path. But if some of you would happen to work on an issue really close to wontfixed one, they won't even notice that they could write a line or two to fix it. And if someone will look for an issue to start from, easy hacks could be helpful for them.

So I echo the proposal, please consider extending the WONTFIX resolution so that it could be categorized well.
i agree with comment 1; the reasons for wontfix'ing a bug are quite broad, so a comment should be used to describe the reason for marking a bug as wontfix.
Yes, I agree that the _reason_ could be whatever; and comments are quite a proper place for such things. As I see it, the proposition is not about reasons; rather, it's about developers' attitude to the following possible destiny of an issue (note that it's not necessarily a bug; it may be an enhancement). And these attitudes are less numerous; they may be categorized in less than a dozen fixed terms. If someone sees an issue which was wontfixed because devs think it's unimportant, and marked "patches welcome" - it's really different from the case when it was wontfixed because devs think it already has a resolution (such as an extension). In first case, someone might come and take it, and make a patch (that would possibly be accepted). In the second, the very marking warns that there's no need to work on it. And possibility to make a search for such markings could be useful for those who have time and resources to spend on things that core devs regard less important.
(In reply to Byron Jones ‹:glob› from comment #7)
> i agree with comment 1; the reasons for wontfix'ing a bug are quite broad,

That looks to me like a point in favor of this bug rather than against it.
I'm not saying the details of my proposal are all ready for production, but I believe we could come up with a limited set of qualifiers if we really tried.
E.g. there seems to be a clear dividing line between

wontfix - rejected (for bad ideas that will never land) vs.
wontfix - interested (for good or potentially good ideas that are too small, too big, not yet developed enough, or whatever to be fixed by main developers, but patches or addons to test would be welcome)

Again, the terms may not be ideal, but you get the idea.

> so a comment should be used to describe the reason for marking a bug as
> wontfix.

Yes, comments are needed to explain the detailed reason of wontfix decision.
But comments are not systematically searchable in any way when looking for bugs of a certain type (e.g. wontfix-badidea vs. wontfix-patcheswelcome).

Perhaps we may find other ways of systematically qualifying wontfix decisions with searchable qualifiers, e.g. using keywords for common reasons (e.g. wontfix-rejected or wontfix-trivial or wontfix-hasaddon or wontfix-needsaddon).

The current implementation of WONTFIX resolution is an unqualified blanket wontfix and I do believe it's worth exploring the potential benefit of somehow turning it into a qualified wontfix where such qualifiers are searchable in a systematic manner. Comment 6 and comment 8 (which came in after I had written this one) mentions some of the potential benefits.
Comment 3 shot down this RFE as INVALID claiming that it was in the wrong component, and because "bad ideas are invalid".

Wrong component has been rectified by "Nobody@mozilla.org" between comment 5 and comment 6 (see history of this bug), so this is no longer invalid.

Definition of INVALID per https://bugzilla.mozilla.org/page.cgi?id=fields.html#status:

> The problem described is not a bug.

Apparently, INVALID resolution can only be used for bugs. Otherwise, that definition fails to explain itself for RFEs, but I think we could safely translate this for RFEs as:

> The problem described is not a valid RFE.

E.g. RFEs that violate basic UX principles or are technically impossible to realize, or they assume technical conditions, current behaviours, current UI etc. that don't exist.

Clearly, this RFE does not fall into any of these categories, so the current resolution (INVALID) is in itself invalid.

The truth is that it was rejected "WONTFIX" already in comment 1 without any substantial discussion or consideration of the underlying needs and intentions, which are still very valid to this day (see dependants of bug 577944 for examples where good ideas get lost because of blanket, unspecified "WONTFIX" resolution).

I'm open to any other better solution, but to deny the problem won't make it go away. Another solution might be to use keywords (instead of value pair resolution) to differentiate between wontfix-has_addon, wontfix-addonwanted, wontfix-rejected or any better terms to express these ideas and make them systematically searchable.
Severity: normal → enhancement
Resolution: INVALID → WONTFIX
(In reply to Mike Kaganski from comment #6)
> if some of you would happen to work on an issue really close to wontfixed
> one, they won't even> notice that they could write a line or two to fix it.
> And if someone will look for an issue to start from, easy hacks could be
> helpful for them.
> So I echo the proposal, please consider extending the WONTFIX resolution so
> that it could be categorized well.

(In reply to Mike Kaganski from comment #8)
> it's about developers' attitude to the following possible
> destiny of an issue (note that it's not necessarily a bug; it may be an
> enhancement). And these attitudes are less numerous; they may be categorized
> in less than a dozen fixed terms. If someone sees an issue which was
> wontfixed because devs think it's unimportant, and marked "patches welcome"
> - it's really different from the case when it was wontfixed because devs
> think it already has a resolution (such as an extension). In first case,
> someone might come and take it, and make a patch (that would possibly be
> accepted). In the second, the very marking warns that there's no need to
> work on it. And possibility to make a search for such markings could be
> useful for those who have time and resources to spend on things that core
> devs regard less important.

Can this issue be revisited?
The discussion so far portrayed the question as a choice between comments and an additional status field while they are not mutually exclusive. On the contrary, why not use both (a comment + the suggested status field to classify the comment) ?

Mike Kaganski makes a strong nuts-and-bolts point above. Many good arguments have been brought forward in favour of the enhancement. What are the counterarguments, if any?
Hi, I'm looking at this and drafting a response. I'll get back to you all by this Wednesday.
Flags: needinfo?(ehumphries)
It's been a long time since we took a long look at bug lifecycle. 

I've convened a small working group to discuss changes to bug states, please reach out to me if you want to join the conversation. 

I don't have a date for a public draft or can guarantee that we'll change things, but I'm reopening this bug as it's dependent on the discussion.
Assignee: mozillamarcia.knous → ehumphries
Status: RESOLVED → REOPENED
Flags: needinfo?(ehumphries)
Priority: -- → P3
QA Contact: timeless
Resolution: WONTFIX → ---
(In reply to Emma Humphries, Bugmaster ☕️🎸🧞‍♀️✨ (she/her) [:emceeaich] (UTC-8) needinfo? me from comment #13)
> I've convened a small working group to discuss changes to bug states

Thank you for the information and the invitation.

> reach out to me if you want to join the conversation.

how? I've tried email twice, unsuccessfully.
Flags: needinfo?(ehumphries)

Closing this again. Any approach to changes in bug lifecycle will not involve separate resolutions for wontfix.

Status: REOPENED → RESOLVED
Type: task → enhancement
Closed: 14 years ago4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.