[Collector] Strange reject policy
I got a reject message for "http://collector.zope.org/Zope/444" with the comment: ZClasses are not being actively maintained, so unless you provide a patch, it is not likely to be fixed. I see this as a strange reject policy. In my view, bug reports in the collector should only be rejected when they are not bugs or when they can not longer occur. We want that people with strange effects look into the collector to find out whether this is a known problem, don't we? Rejected bug reports are much more difficult to find than open ones. In this case, the issue reports a true bug which pose a potential security risk because a permission mapping unexpectedly has no effect. I do not argue that this bug needs a fix but the report should at least be easily found. -- Dieter
In retrospect I probably should have just marked it as deferred rather than rejected, the idea was more to provoke action (which I did) then to reject it as not-a-bug. -Casey On Fri, 30 Apr 2004 17:54:58 +0200 Dieter Maurer <dieter@handshake.de> wrote:
I got a reject message for "http://collector.zope.org/Zope/444" with the comment:
ZClasses are not being actively maintained, so unless you provide a patch, it is not likely to be fixed.
I see this as a strange reject policy.
In my view, bug reports in the collector should only be rejected when they are not bugs or when they can not longer occur. We want that people with strange effects look into the collector to find out whether this is a known problem, don't we? Rejected bug reports are much more difficult to find than open ones.
In this case, the issue reports a true bug which pose a potential security risk because a permission mapping unexpectedly has no effect.
I do not argue that this bug needs a fix but the report should at least be easily found.
-- Dieter
On Fri, 2004-04-30 at 13:43, Casey Duncan wrote:
In retrospect I probably should have just marked it as deferred rather than rejected, the idea was more to provoke action (which I did) then to reject it as not-a-bug.
I think there needs to be another category named "wontfix" that doesn't imply that it will ever be fixed like "deferred" seems to. This category should also be selected in the default search settings. - C
On Fri, 30 Apr 2004 13:46:26 -0400 Chris McDonough <chrism@plope.com> wrote:
On Fri, 2004-04-30 at 13:43, Casey Duncan wrote:
In retrospect I probably should have just marked it as deferred rather than rejected, the idea was more to provoke action (which I did) then to reject it as not-a-bug.
I think there needs to be another category named "wontfix" that doesn't imply that it will ever be fixed like "deferred" seems to. This category should also be selected in the default search settings.
+1 I volunteer Chris to implement it ;^) -Casey
Chris McDonough <chrism@plope.com> wrote:
I think there needs to be another category named "wontfix" that doesn't imply that it will ever be fixed like "deferred" seems to. This category should also be selected in the default search settings.
Later, Chris McDonough wrote:
On Fri, 2004-04-30 at 13:59, Casey Duncan wrote:
I volunteer Chris to implement it ;^)
Just tried. I thought it was just a setting in the ZMI, but it's not. :-( Someone go get Ken!! ;-)
:-) Done. The piece you were missing is that the categories are actually states in the collector_issue_workflow. I added a "Wontfix" state and a "refuse" transition (bringing to a total of three the transitions by which issues are dodged:), and hooked them into the existing lattice. This was easy. Other issues with our collector/issue-handling process are not so easy (particularly the security controversy). I'm going to try to take some responsibility for getting attention on those issues, since i have a bit of between-deadlines breathing space. Ken klm@zope.com
Ken Manheimer wrote:
Done. The piece you were missing is that the categories are actually states in the collector_issue_workflow. I added a "Wontfix" state and a "refuse" transition (bringing to a total of three the transitions by which issues are dodged:), and hooked them into the existing lattice.
Yay! Does this mean we have a fully functional "wont fix" state now?
This was easy. Other issues with our collector/issue-handling process are not so easy (particularly the security controversy). I'm going to try to take some responsibility for getting attention on those issues, since i have a bit of between-deadlines breathing space.
Cool. Some kind of policy that we can point new-issue-resolvers at to clarify what should be rejected/accepted/wont-fix'ed would be really handy... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote:
Ken Manheimer wrote:
Done. The piece you were missing is that the categories are actually states in the collector_issue_workflow. I added a "Wontfix" state and a "refuse" transition (bringing to a total of three the transitions by which issues are dodged:), and hooked them into the existing lattice.
Yay! Does this mean we have a fully functional "wont fix" state now?
It does appear to, woohoo! Can we change the action name from "Refuse" to "Won't Fix"? I took a while to find it... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Thanks for this Ken! On Thu, 2004-05-06 at 07:57, Chris Withers wrote:
Chris Withers wrote:
Ken Manheimer wrote:
Done. The piece you were missing is that the categories are actually states in the collector_issue_workflow. I added a "Wontfix" state and a "refuse" transition (bringing to a total of three the transitions by which issues are dodged:), and hooked them into the existing lattice.
Yay! Does this mean we have a fully functional "wont fix" state now?
It does appear to, woohoo!
Can we change the action name from "Refuse" to "Won't Fix"? I took a while to find it...
Chris
On Thu, 6 May 2004, Chris Withers wrote:
Chris Withers wrote:
Yay! Does this mean we have a fully functional "wont fix" state now?
It does appear to, woohoo!
Can we change the action name from "Refuse" to "Won't Fix"? I took a while to find it...
All the actions are verbs, "won't fix" is not a verb. Can you suggest a verb the more clearly indicates the result is "won't fix"? (While the distinction between "refuse" and "reject" is subtle, "reject" distinctly implies to me a defect in the request, while refuse does not.) I'm hoping the difference is clear enough to be mnemonic, once you get it, at least. One small thing i think would be a big help would be to include html titles on each action so that browser mouse-over help bubbles would indicate the effect of each action. I don't even recall whether there's any "help" for the issue-followup form, but some text there could also be um helpful. (Patches appreciated.) Ken
From: "Ken Manheimer" <klm@zope.com>
All the actions are verbs, "won't fix" is not a verb. Can you suggest a verb the more clearly indicates the result is "won't fix"?
Tough one... "Live with" "Ignore" "Keep this bug as is" "Zenify" "Featurize" (as in "This is not a bug, it's a feature") "Shove under carpet" "Forget" "Procrastinate" "Pretend to be deaf" Hmm...
On Thu, 2004-05-06 at 11:56, Lennart Regebro wrote:
From: "Ken Manheimer" <klm@zope.com>
All the actions are verbs, "won't fix" is not a verb. Can you suggest a verb the more clearly indicates the result is "won't fix"?
Tough one...
"Live with" "Ignore" "Keep this bug as is" "Zenify" "Featurize" (as in "This is not a bug, it's a feature") "Shove under carpet" "Forget" "Procrastinate" "Pretend to be deaf"
How about "Refuse to fix"? Cheers, leo -- Ideas don't stay in some minds very long because they don't like solitary confinement.
Or maybe "Deny" as a action? Sounds less angry than "reject" and "refuse".
On Thu, 6 May 2004, Lennart Regebro wrote:
Or maybe "Deny" as a action? Sounds less angry than "reject" and "refuse".
What's being denied - the request to fix the bug, or the validity of the bug report? "Refuse" suggests only that we are refusing to fix the bug, there's no implication that the bug request is inaccurate. (As a noun, "refuse" has the connotation of "garbage", but there's no tinge of that when used as a verb.) Ken klm@zope.com
On Thu, 06 May 2004 12:09:18 -0300 Leonardo Rochael Almeida <leo@hiper.com.br> wrote:
On Thu, 2004-05-06 at 11:56, Lennart Regebro wrote:
From: "Ken Manheimer" <klm@zope.com>
All the actions are verbs, "won't fix" is not a verb. Can you suggest a verb the more clearly indicates the result is "won't fix"?
Tough one...
"Live with" "Ignore" "Keep this bug as is" "Zenify" "Featurize" (as in "This is not a bug, it's a feature") "Shove under carpet" "Forget" "Procrastinate" "Pretend to be deaf"
How about: "Dis" "Blow-off" "Lose" "Getouttahere" Or perhaps a passive-aggressive bent: "Agree" "Yup" "IDontDisagree" "HowNice" Or my personal favorite: "Interesting" -Casey
[Ken Manheimer]
All the actions are verbs, "won't fix" is not a verb. Can you suggest a verb the more clearly indicates the result is "won't fix"?
Sorry, I got lost on the first sentence: what difference does it make to anything whether they're verbs, adjectives, a mix, ...? They're all just cryptically abbreviated answers to the question "what do you want to do with this report?". "We want to resolve it." "Sorry, we want to reject it". "Sorry, but while it is arguably a bug, we won't fix it." If someone claims they can't understand what "won't fix" means, I'll be sympathetic. Until then, "won't fix" sounds perfect to me.
On Thu, 6 May 2004, Tim Peters wrote:
[Ken Manheimer]
All the actions are verbs, "won't fix" is not a verb. Can you suggest a verb the more clearly indicates the result is "won't fix"?
Sorry, I got lost on the first sentence: what difference does it make to anything whether they're verbs, adjectives, a mix, ...? They're all just cryptically abbreviated answers to the question "what do you want to do with this report?".
Hmm. It can sometimes pay off in workflow configuration to consistently pick verbs that describe the actions in a generic way, so the workflows are consistent with other workflows for similar but separate activities. Sorta like generic APIs. Taking a step back (with a well aimed nudge), it doesn't look like this is really helpful here. I'll change it the action name to "wontfix". (It'd be painful to accommodate punctuation in the action or state names, so if that spelling is too obscure, "refuse" may still be preferable.) (Is it just me, or is there sometimes a fine line between "consistency" and "foolish consistency"?) enquiring-small-minds-want-to-know'ly, Ken klm@zope.com
Ken Manheimer wrote at 2004-5-7 09:42 -0400:
... It can sometimes pay off in workflow configuration to consistently pick verbs that describe the actions in a generic way
You can view "won't fix" as a verb, like in "we won't fix this bug". -- Dieter
On Fri, 7 May 2004, Dieter Maurer wrote:
Ken Manheimer wrote at 2004-5-7 09:42 -0400:
... It can sometimes pay off in workflow configuration to consistently pick verbs that describe the actions in a generic way
You can view "won't fix" as a verb, like in
"we won't fix this bug".
Well, the action now is called "wontfix". (Next time i or someone gets time, it would not take much to repair my stupid misunderstanding about .listFilteredActionsFor() to get a nicer "Won't fix" lable associated with the action.) I must say (since the conversation's continuing), i still like "refuse". If there were a chance that collector issues were to be managed with other kinds of requests - for access, property, appointments, etc - then i could see where "wontfix" is too specific - they could all be acted on with "accept", "refuse", "reject", etc. But that generalization probably ain't gonna happen, not with this incarnation of the collector. Also, the action for taking on a request in order to fix the problem is not called "Will fix", it's "accept". "Refuse" is a nicer complement than "wontfix". Still, "wontfix" is easier to recognize in the context of bug reports, so what the heck. Ken klm@zope.com
On Thu, 6 May 2004, Leonardo Rochael Almeida wrote:
On Thu, 2004-05-06 at 11:56, Lennart Regebro wrote:
From: "Ken Manheimer" <klm@zope.com>
All the actions are verbs, "won't fix" is not a verb. Can you suggest a verb the more clearly indicates the result is "won't fix"?
Tough one...
"Live with" "Ignore" "Keep this bug as is" "Zenify" "Featurize" (as in "This is not a bug, it's a feature") "Shove under carpet" "Forget" "Procrastinate" "Pretend to be deaf"
How about "Refuse to fix"?
How is that better than what i implemented, "Refuse"? (Or maybe you missed that, since it's not in the excerpt context?) As the discussion has proceeded i'm becoming more convinced that "refuse" is fine... Ken klm@zope.com
Ken Manheimer wrote:
How is that better than what i implemented, "Refuse"? (Or maybe you missed that, since it's not in the excerpt context?) As the discussion has proceeded i'm becoming more convinced that "refuse" is fine...
...and I'm more convinced that "wont fix" is better. This is what SourceForge does, iirc ;-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On Thu, May 06, 2004 at 04:56:42PM +0200, Lennart Regebro wrote:
"Featurize" (as in "This is not a bug, it's a feature")
That's my favorite bug-closing technique! "Closed" works pretty well for that one, though in order to really justify it I feel compelled to add comments, docstrings, and/or help text noting the bug^H^H^Hfeature. -- Paul Winkler http://www.slinkp.com
On Thu, 6 May 2004, Lennart Regebro wrote:
From: "Ken Manheimer" <klm@zope.com>
All the actions are verbs, "won't fix" is not a verb. Can you suggest a verb the more clearly indicates the result is "won't fix"?
Tough one...
"Live with" "Ignore" "Keep this bug as is" "Zenify" "Featurize" (as in "This is not a bug, it's a feature") "Shove under carpet" "Forget" "Procrastinate" "Pretend to be deaf"
For any of these that you were suggesting in earnest - i think "refuse" is more direct. (I would be tempted by one that went, "la la la i'm not listening i can't hear you" even though it isn't a verb, and it'd make the form twice as wide...-) Ken
Ken Manheimer wrote:
All the actions are verbs, "won't fix" is not a verb.
Do we have to be this pedantic? "Wont' fix" says what it does, it's close enough to verb usage for me: "I won't fix that"
verb the more clearly indicates the result is "won't fix"? (While the distinction between "refuse" and "reject" is subtle, "reject" distinctly implies to me a defect in the request, while refuse does not.)
Yeah, but refuse doesn't have any logical associate with the "won't fix" state for me, so it's a very unintuitive name... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On Fri, 7 May 2004, Chris Withers wrote:
Ken Manheimer wrote:
All the actions are verbs, "won't fix" is not a verb.
Do we have to be this pedantic?
I wasn't meaning to be pedeantic. Sometimes inconsistencies in tense, grammatical form, etc, can make a web form unbeably confusing - what's right is not always clear. Tim's identifying the question the users will have in their minds - "what do you want to do with this report" - rang true, and addressed my concerns. I'm going to change the action to "wontfix".
verb the more clearly indicates the result is "won't fix"? (While the distinction between "refuse" and "reject" is subtle, "reject" distinctly implies to me a defect in the request, while refuse does not.)
Yeah, but refuse doesn't have any logical associate with the "won't fix" state for me, so it's a very unintuitive name...
The fact that you couldn't find the intended action when you first looked is an indication that the action isn't very clear. That said, sometimes the simplest clearest thing for one person isn't so for another, or is misleading (particularly to the chronically literal minded like me). In this case, though, "wontfix" will probably be clear to everyone - if they can get past the smashing together of the two words. I'd have to change other stuff to deal with a delimited pair of words, and don't want to mess with that if i can avoid it. Ken klm@zope.com
--On Donnerstag, 6. Mai 2004 12:37 Uhr +0100 Chris Withers <chris@simplistix.co.uk> wrote:
Ken Manheimer wrote:
Done. The piece you were missing is that the categories are actually states in the collector_issue_workflow. I added a "Wontfix" state and a "refuse" transition (bringing to a total of three the transitions by which issues are dodged:), and hooked them into the existing lattice.
Yay! Does this mean we have a fully functional "wont fix" state now?
A state we_can_live_with_that would be fine as well :-) -aj
On Thu, 6 May 2004, Andreas Jung wrote:
--On Donnerstag, 6. Mai 2004 12:37 Uhr +0100 Chris Withers <chris@simplistix.co.uk> wrote:
Ken Manheimer wrote:
Done. The piece you were missing is that the categories are actually states in the collector_issue_workflow. I added a "Wontfix" state and a "refuse" transition (bringing to a total of three the transitions by which issues are dodged:), and hooked them into the existing lattice.
Yay! Does this mean we have a fully functional "wont fix" state now?
A state we_can_live_with_that would be fine as well :-)
That's either "Reject" or "Defer" with "We can live with that (/for now)." body. I can envision a little action qualifier text box, where the supporter can put in a brief message that describes the reason for their action. It would (in my fantasy vision) have an accompanying select box that is populated with the catalog-collected uniqueValuesFor() for that action. (Javascript would jam the values in the select box when the supporter picks an action, from the selections for all the available actions prepopulated in a hidden field). This way the supporter could add a new reason, if none of the conventional (already-in-use) ones suit. While i love this prospect - fits my ideal of adaptive collaboration - i'm not sure the extra precision outweighs the extra complexity - and who has time to implement this, anyway?-) Ken
[Chris McDonough]
I think there needs to be another category named "wontfix" that doesn't imply that it will ever be fixed like "deferred" seems to. This category should also be selected in the default search settings.
+1. The Python bug tracker has a WontFix, and it's proved valuable in practice to distinguish that from "fixed" and "rejected".
participants (11)
-
Andreas Jung -
Casey Duncan -
Chris McDonough -
Chris Withers -
Dieter Maurer -
Jamie Heilman -
Ken Manheimer -
Lennart Regebro -
Leonardo Rochael Almeida -
Paul Winkler -
Tim Peters