klm at zope
Jul 30, 2004, 2:44 PM
Post #16 of 31
On Fri, 30 Jul 2004, Chris McDonough wrote:
Re: [Zope-dev] Re: Collector Status Meanings
[In reply to]
> On Fri, 2004-07-30 at 14:44, Chris Withers wrote:
> > > But needing to wade through a bunch of wontfixes that are just responses
> > > to bad bugreporting
> > These should be rejected, not wontfix'ed. And most of the time they now
> > are. If I find any wontfix'es like this, I'd reject them, And given I
> > went through ALL the wontfix'es today, I don't think there are any like
> > this...
> Ya, you're right about this, I agree.
Right - "wontfix" is not for illegitimate reports, it's for legitimate
reports that cannot be fixed for practical reasons.
> But still I would just never think to go through the "wontfix" entries
> on a bug day or any other time... I would think it would be a waste of
> time because I think of wontfix as a terminal state never to be looked
> at again except as a historical curiosity. I think this may have to do
> with your definition of "wontfix", which differs from mine:
> This means that the bug or feature request the issue refers to has
> been accepted as valid but will not be dealt with for the
> forseeable future.
> Reasons for this may include:
> Bugs in deprecated components of Zope.
> OK, I agree with that.
> Bugs that are believable but that cannot be reproduced either by
> the submitter or the wontfix'er.
> I would mark this "rejected" or "pending rejection". I'm not sure what
> "believable" means here; it's a little too fuzzy.
I *really* don't think the "pending rejection" distinction adds value.
If you think there's real doubt about the disqualification, then mark it
deferred with a note about the doubts, and eventually it should be
harvested and sent to rejected if there's not followup. (It would be
really nice if we could put an "expiration date" on the thing, whereon it
gets moved to rejected automatically...)
> Bugs where there is no solution but a common workaround which means
> the bug should never be excercised.
> OK, agreed.
> Features that don't have a champion and so are unlikely to be
> I would call this "deferred".
> Changes that don't fix a bug or add a new feature, and don't have a
> champion, or haven't see activity in a long time.
> I would also call this "deferred".
And here, too.
> > > The difference is that some pending items haven't even been looked at in
> > > earnest. I usually put things in deferred only after I've spent a
> > > half-hour or hour or so trying to fix the thing and I've realized that
> > > it might take, say, a week to actually fix it. OTOH, if I spent two
> > > minutes trying to fix something and fail but I still have no idea how
> > > long it would actually take to fix, I leave it in pending state.
> > Okay, but other people don't do this, or see the difference.
> > For me, it's easy enough to page through http://collector.zope.org/Zope
> > and see the pending entries and see which ones of those have followups
> > and which ones don't...
> Really? There's like more than 200 of them, right? That could take a
> while.. although granted you get to know them after a while. ;-)
I think pending versus deferred (versus rejected) aids the triage process
for difficult-to-place items. Here's a proposal for a working model:
- Easy to place things are handled (rejected, accepted, wontfixed, etc).
- Newish hard-to-place things are left in pending - maybe someone will
step forward to fix it, or have insight about why it shouldn't/can't
- Languishing hard-to-placers that are not so important are moved to
deferred, to get out of the way of the more important pending items.
If someone complains, the importance can be reevaluated.
- Obviously perpetual deferred items can be reassessed and moved to
Clearly that last is a very mooshy judgement call - but at least we've
given every chance for the judgement applied to an item to be
reflected in its evolving status.
> > > I'm not sure I care enough to further argue, but I'll note that you're
> > > suggesting that we change the meaning of deferred to something other
> > > than long-term-pending and communicating this decision to all longtime
> > > collector participants is gonna be hard and the result will probably be
> > > confusing.
> > Well, at least there's a wiki page describing what the states mean now.
> > I was contemplating linking that from the followup form just below/above
> > the radio buttons for slecting the type of followup. Should I?
> I think that would be a good idea, my disagreements notwithstanding.
> Thanks for doing this, BTW.
I also appreciate that this is getting resolved, and think it's important
to get the agreed-upon state-definitions there. We need to resolve the
definitions. I think some of the objections (eg deferred vs pending vs
wontfix) is due to noise resulting from inconsistent use of/understanding
of the states across supporters. I think that more clear common
understanding would reduce the cause for objections...
> > FWIW: had it been trivial to add a new state, I would have done, it
> > wasn't so I didn't :-S
> Would you be willing add a "pending rejection" state, Ken? Or if you
> tell me how to do it, I could do it.
I'll have to think about this more. I'm inclined to think that a state
partway between pending and rejected is not too helpful - and there are
other items languishing in deferred that can eventually be discovered to
be rejectable, even if they weren't put there for the purpose. And useful
though "wontfix" and "deferred" are, clearly they add a level of nuance
that allows for misunderstanding which is occurring. I'd rather not add
> If Ken added a pending rejection state, would it be reasonable to use
> that instead of deferred to mean "pending rejection"?
I haven't been using the collector for the breadth of issues as those that
come up in the zope collector, so i would ask - does what i proposed above
(Regardless of that, adding a state is mostly simple adjustment of the
workflow, with one change to the code to enable exposure of the new state
among the supporter-actions buttons, iirc.)
klm [at] zope
Zope-Coders mailing list
Zope-Coders [at] zope