Mailing List Archive

These definitions are how I've understood them since the inception of
the collector.

What I think Chris wants to do is to have a state that means "pending
rejection". He has defined "deferred" to mean this. I would prefer an
explicit "pending rejection" state, FWIW.

- C


On Fri, 2004-07-30 at 11:50, Ken Manheimer wrote:
> On Fri, 30 Jul 2004, Chris Withers wrote:
>
> > Apologies for the cross-posting, but I think this is relevent to all
> > these lists.
>
> I think this is a valuable discussion. I don't think cross-posted
> discussions work, though, so i'm replying in the various groups (except
> zope-collector-monitor, which is only meant for collector-originating
> submissions) with a followup to zope-coders.
>
> > I've summarised the meaning of the various collector states here:
> >
> > http://dev.zope.org/CVS/CollectorStatuses
> >
> > Please let me know if you disagre with any of that, although I'm pretty
> > sure they're right and will argue with anyone who thinks otherwise ;-)
>
> My intent for the states is different from what you suggested, in some
> cases significantly. It may be that the practice is more like you
> describe and makes more sense, i dunno, but here's what i intended:
>
> Pending: Issues that have not yet been settled or assigned to some
> supporter, and warrant attention.
>
> Your description, "issues that haven't been considered",
> assumes that issues are always assigned or settled when they
> are examined, while i think some issues can remain in the
> pending state awaiting resource availability.
>
> Accepted: Issues that some supporter(s) has responsibility for resolving
> it, and it is not yet resolved.
>
> Your description says that some supporter has assessed the
> issue as warranting repair, and later says that the the issue
> has an assigned supporter. I think it's a lot clearer to
> directly say that an accepted issue has a supporter
> responsible for resolving it.
>
> Rejected: Issues that are settled as being somehow invalid or outside
> the scope of the system the collector serves.
>
> Resolved: Issues that are settled as having been solved.
>
> Deferred: Issues that are not assigned or settled but warrant revisiting
> at some later occasion. This enables, for instance, putting
> an issue aside until more information is collected.
>
> Wontfix: Issues that are settled as ones that won't be fixed. These
> issues are within the scope of the collector, but would
> require more effort than they're worth. (Sustained lack of a
> champion who will take responsibility for solving the issue
> is one sign of that.)
>
> _______________________________________________
> Zope-Dev maillist - Zope-Dev@zope.org
> http://mail.zope.org/mailman/listinfo/zope-dev
> ** No cross posts or HTML encoding! **
> (Related lists -
> http://mail.zope.org/mailman/listinfo/zope-announce
> http://mail.zope.org/mailman/listinfo/zope )
>

_______________________________________________
Zope-Coders mailing list
Zope-Coders@zope.org
http://mail.zope.org/mailman/listinfo/zope-coders

Fred Drake wrote:
> I don't think it makes sense to use this to indicate a supporter (and
> possibly some of their time) has been allocated to deal with the
> issue; the list of assigned supporters should be sufficient for that.
> If the list is empty, no supporter has been assigned.
>
> I think "Accepted" should be used to indicate that the issue is real
> and still needs to be addressed in some way. This is independent of
> assigning it to one or more specific supporters.

I totally agree. Unfortunately, the mechanics of the collector
automatically assign the person who marks the bug as accepted :-)

Chris

--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
_______________________________________________
Zope-Coders mailing list
Zope-Coders@zope.org
http://mail.zope.org/mailman/listinfo/zope-coders

Chris McDonough wrote:
>
> What I think Chris wants to do is to have a state that means "pending
> rejection". He has defined "deferred" to mean this. I would prefer an
> explicit "pending rejection" state, FWIW.

*shrugs*

It's easier to re-use a useless state than add a new one.

We have wontfix for what people used to genuinely use deferred for.

The others were just using it as a dumping ground :-(

Chris

--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
_______________________________________________
Zope-Coders mailing list
Zope-Coders@zope.org
http://mail.zope.org/mailman/listinfo/zope-coders

On Fri, 2004-07-30 at 13:11, Chris Withers wrote:
> Chris McDonough wrote:
> >
> > What I think Chris wants to do is to have a state that means "pending
> > rejection". He has defined "deferred" to mean this. I would prefer an
> > explicit "pending rejection" state, FWIW.
>
> *shrugs*
>
> It's easier to re-use a useless state than add a new one.

I don't think deferred is useless. I used deferred to mean "stuff that
isn't so important that it needs to be fixed now, but stuff that should
be fixed nonetheless". IOW, deferred to me means it's been looked at,
it's been determined to be a real problem, but it's just not possible to
fix given resource constraints. "Wontfix" doesn't mean this to me;
instead it means it just won't get fixed ever.

I don't think it's important to move all issues from pending/deferred to
a "terminal" state like "wontfix"/"rejected"/"resolved". It's ok to
leave some issues pending long-term, and this is what "deferred" is
for. If that's a "dumping ground", I think it's ok.

- C


>
> We have wontfix for what people used to genuinely use deferred for.
>
> The others were just using it as a dumping ground :-(
>
> Chris

_______________________________________________
Zope-Coders mailing list
Zope-Coders@zope.org
http://mail.zope.org/mailman/listinfo/zope-coders

Chris McDonough wrote:
> I don't think deferred is useless. I used deferred to mean "stuff that
> isn't so important that it needs to be fixed now, but stuff that should
> be fixed nonetheless".

Sutff in this state can be left in pending, as most of it is now...

> IOW, deferred to me means it's been looked at,
> it's been determined to be a real problem, but it's just not possible to
> fix given resource constraints.

pending with a comment is how this works in practice...

> "Wontfix" doesn't mean this to me;
> instead it means it just won't get fixed ever.

Yep, but there's nothing stopping people picking up a wontfix if they
want to fix it, it just means it's taken out of the default issue list...

> I don't think it's important to move all issues from pending/deferred to
> a "terminal" state like "wontfix"/"rejected"/"resolved".

I agree, but I don't want them put in a "deferred" state which hides
them and might as well BE terminal...

> It's ok to
> leave some issues pending long-term, and this is what "deferred" is
> for. If that's a "dumping ground", I think it's ok.

They can stay in the pending state then, plenty of issues stay in the
pending state for years, so I see no difference between your use of
deferred and the current use of pending...

Chris

--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
_______________________________________________
Zope-Coders mailing list
Zope-Coders@zope.org
http://mail.zope.org/mailman/listinfo/zope-coders

On Fri, 2004-07-30 at 13:54, Chris Withers wrote:
> Chris McDonough wrote:
> > I don't think deferred is useless. I used deferred to mean "stuff that
> > isn't so important that it needs to be fixed now, but stuff that should
> > be fixed nonetheless".
>
> Sutff in this state can be left in pending, as most of it is now...
>
> > IOW, deferred to me means it's been looked at,
> > it's been determined to be a real problem, but it's just not possible to
> > fix given resource constraints.
>
> pending with a comment is how this works in practice...

Maybe your practice... that's not how I've done it. My understanding of
the states has always been what Ken showed.

> > "Wontfix" doesn't mean this to me;
> > instead it means it just won't get fixed ever.
>
> Yep, but there's nothing stopping people picking up a wontfix if they
> want to fix it, it just means it's taken out of the default issue list...

But needing to wade through a bunch of wontfixes that are just responses
to bad bugreporting to find the couple that were actually just blocked
on a lack of resources is kinda silly. I won't do it; I can't imagine
someone else doing it.

> > It's ok to
> > leave some issues pending long-term, and this is what "deferred" is
> > for. If that's a "dumping ground", I think it's ok.
>
> They can stay in the pending state then, plenty of issues stay in the
> pending state for years, so I see no difference between your use of
> deferred and the current use of pending...

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.

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.

- C


_______________________________________________
Zope-Coders mailing list
Zope-Coders@zope.org
http://mail.zope.org/mailman/listinfo/zope-coders

[.I'm only following up to zope-coders. I tried in my initial followup to
redirect the zope-dev side to zope-coders, and strongly ask that we not
try to conduct a multi-list discussion. Some people wind up responding in
the midst of a thread only to one list and some the other, and it winds up
making for lots of discrepancy and chaos.]

On Fri, 30 Jul 2004, Fred Drake wrote:

> On Fri, 30 Jul 2004 11:50:57 -0400 (EDT), Ken Manheimer <klm@zope.com> wrote:
> > Accepted: Issues that some supporter(s) has responsibility for resolving
> > it, and it is not yet resolved.
> >
> > Your description says that some supporter has assessed the
> > issue as warranting repair, and later says that the the issue
> > has an assigned supporter. I think it's a lot clearer to
> > directly say that an accepted issue has a supporter
> > responsible for resolving it.
>
> I don't think it makes sense to use this to indicate a supporter (and
> possibly some of their time) has been allocated to deal with the
> issue; the list of assigned supporters should be sufficient for that.
> If the list is empty, no supporter has been assigned.
>
> I think "Accepted" should be used to indicate that the issue is real
> and still needs to be addressed in some way. This is independent of
> assigning it to one or more specific supporters.

The collector is specifically built to not allow an issue being in the
accepted state without having any supporters. "Accepted" is for putting
your money (or someone else's, but they can retaliate:-) where your mouth
is. This is fundamental to the design of the collector (you can't resign
an issue and have it remain accepted when you're the only supporter on
it), and i adamantly don't think it should be changed.

The thing we specifically want to avoid is the classic, otherwise
inevitable tendency of people to say, "Yeah, someone oughtta do that"
without actually making a commitment. Without some kind of check,
and particularly if someone else *might* take care of it, people will
"accept" anything remotely feasible and useful.

Issues that warrant attention but don't not enough to justify someone
taking responsibility for it should either remain pending - which means
continuing pain for the people triaging issues - or be deferred, which
means it may languish. But it should not be impossible to say "yeah,
someone oughtta do this" without putting someone on the hook for it.

This is why i want to restate what chris wrote to simply say that
"accepted" is an issue which someone has taken the responsibility to
resolve.

I also think it's not quite right to suggest that someone wishing to join
the effort to work on an accepted issue should contact the supporters -
accepting/assigning yourself *will* contact the assigned supporters.
What we probably want to suggest is that you should explain how you want
to help if you assign yourself to an accepted issue.

Ken
_______________________________________________
Zope-Coders mailing list
Zope-Coders@zope.org
http://mail.zope.org/mailman/listinfo/zope-coders

Ken Manheimer wrote:
>
> I also think it's not quite right to suggest that someone wishing to join
> the effort to work on an accepted issue should contact the supporters -
> accepting/assigning yourself *will* contact the assigned supporters.

Yes, but you can't assign yourself unless you're a tracker supporter, right?

I'd prefer not to cut offer potential helpers purely because they're not
tracker supporters.

Two minor bugs got fixed in just this way today...

Chris

--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
_______________________________________________
Zope-Coders mailing list
Zope-Coders@zope.org
http://mail.zope.org/mailman/listinfo/zope-coders

Chris McDonough wrote:
>
> Maybe your practice... that's not how I've done it. My understanding of
> the states has always been what Ken showed.

I'm just going on what I saw by reading a shedload of collector entries
today...

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

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

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

cheers,

Chris

FWIW: had it been trivial to add a new state, I would have done, it
wasn't so I didn't :-S

--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
_______________________________________________
Zope-Coders mailing list
Zope-Coders@zope.org
http://mail.zope.org/mailman/listinfo/zope-coders

On Fri, 30 Jul 2004, Chris Withers wrote:

> Chris McDonough wrote:
> > I don't think deferred is useless. I used deferred to mean "stuff that
> > isn't so important that it needs to be fixed now, but stuff that should
> > be fixed nonetheless".
>
> Sutff in this state can be left in pending, as most of it is now...

I think what your saying amounts to "stuff in deferred languishes because
there's so much of it and nobody looks there, so we should move it to
pending". What i think this will accomplish is make it harder to tell the
difference between stuff that's assessed as being deferrable and stuff
that's not. Why would you want to do that?

I do see value in getting people clearer about what belongs in the
"deferred" state, so we can all benefit from the distinction.

> > IOW, deferred to me means it's been looked at,
> > it's been determined to be a real problem, but it's just not possible to
> > fix given resource constraints.
>
> pending with a comment is how this works in practice...

Evidently not everyone's practice. I think if deferred were understood
and used the way it should be there would be a gain.

> > I don't think it's important to move all issues from pending/deferred to
> > a "terminal" state like "wontfix"/"rejected"/"resolved".
>
> I agree, but I don't want them put in a "deferred" state which hides
> them and might as well BE terminal...

Making things get hidden in Pending, which is worse.

> > It's ok to
> > leave some issues pending long-term, and this is what "deferred" is
> > for. If that's a "dumping ground", I think it's ok.
>
> They can stay in the pending state then, plenty of issues stay in the
> pending state for years, so I see no difference between your use of
> deferred and the current use of pending...

I think if people understood the difference better (thank you for this
effort to make that happen!) it would work better.

Ken
_______________________________________________
Zope-Coders mailing list
Zope-Coders@zope.org
http://mail.zope.org/mailman/listinfo/zope-coders

On Fri, 30 Jul 2004, Ken Manheimer wrote:

> > > It's ok to
> > > leave some issues pending long-term, and this is what "deferred" is
> > > for. If that's a "dumping ground", I think it's ok.
> >
> > They can stay in the pending state then, plenty of issues stay in the
> > pending state for years, so I see no difference between your use of
> > deferred and the current use of pending...
>
> I think if people understood the difference better (thank you for this
> effort to make that happen!) it would work better.

In particular, i think it's better for things to languish in "deferred"
than in "pending". I think it is useful in some cases, and do not think
an artificial 1-month deadline is useful in many cases.

Ken
_______________________________________________
Zope-Coders mailing list
Zope-Coders@zope.org
http://mail.zope.org/mailman/listinfo/zope-coders

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.

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:

Wontfix

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.

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

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

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

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

If Ken added a pending rejection state, would it be reasonable to use
that instead of deferred to mean "pending rejection"?

- C


_______________________________________________
Zope-Coders mailing list
Zope-Coders@zope.org
http://mail.zope.org/mailman/listinfo/zope-coders

Chris McDonough wrote:
> 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.
>
> 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:
>
> Wontfix
>
> 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.
>
> 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
> implemented.
>
> 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".

The major missing reason for "wontfix" is that the requested change
breaks something more important than whatever pain / inconvenience /
itch prompted the request


>>>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'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.
>
>
>>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.
>
> If Ken added a pending rejection state, would it be reasonable to use
> that instead of deferred to mean "pending rejection"?

Tres.
--
===============================================================
Tres Seaver tseaver@zope.com
Zope Corporation "Zope Dealers" http://www.zope.com

_______________________________________________
Zope-Coders mailing list
Zope-Coders@zope.org
http://mail.zope.org/mailman/listinfo/zope-coders

On Fri, 30 Jul 2004, Chris Withers wrote:

> > I also think it's not quite right to suggest that someone wishing to join
> > the effort to work on an accepted issue should contact the supporters -
> > accepting/assigning yourself *will* contact the assigned supporters.
>
> Yes, but you can't assign yourself unless you're a tracker supporter, right?
>
> I'd prefer not to cut offer potential helpers purely because they're not
> tracker supporters.
>
> Two minor bugs got fixed in just this way today...

I wasn't thinking about non-supporter helpers, and wasn't intending to
suggest excluding them. You're right, it would be good to tell them to
contact a supporter if they want to help. In fact, this applies whether
or not the issue is accepted, right? And it's important to indicate that
you're talking about non-supporters, so as to not confuse or mislead
supporters - something like:

If you intend to work on an issue but are not on the collector staff,
add a comment to the issue indicating so. You will not be
able to change the status of the issue, but you can leave remarks about
how it is settled so some supporter can review and settle it
accordingly.

Ken
_______________________________________________
Zope-Coders mailing list
Zope-Coders@zope.org
http://mail.zope.org/mailman/listinfo/zope-coders

On Fri, 30 Jul 2004, Chris McDonough wrote:

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

Rejected.

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
> implemented.
>
> I would call this "deferred".

I agree.

> 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
be fixed.
- 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
wontfix.

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

> 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
sound workable?

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

Ken
klm@zope.com
_______________________________________________
Zope-Coders mailing list
Zope-Coders@zope.org
http://mail.zope.org/mailman/listinfo/zope-coders

Chris McDonough wrote:
> These definitions are how I've understood them since the inception of
> the collector.
>
> What I think Chris wants to do is to have a state that means "pending
> rejection". He has defined "deferred" to mean this. I would prefer an
> explicit "pending rejection" state, FWIW.

I made a quick workflow diagram, and quickly realized that "deferred"
actually ends up as a "need more information" state. It is not pending
rejection, but pending decision in that case. Of course, that is what
the pending state is for...

That in turn means that what is actually missing is a way to distinguish
between something that has just been submitted, and something that
somebody has noticed. So I suggest a "submitted" state, as default state
for new issues, and that we change it to "pending" if we need more info,
or accept/reject/wontfix. Deferred is then either removed or renamed
"pending rejection" to notify the poster that when we ask for more info
we mean it. ;)

My 0.02 EUR...
_______________________________________________
Zope-Coders mailing list
Zope-Coders@zope.org
http://mail.zope.org/mailman/listinfo/zope-coders

Oh, and I think "deferred" as saying "this should be fixed but is not
important" clashes with the Importance field.
_______________________________________________
Zope-Coders mailing list
Zope-Coders@zope.org
http://mail.zope.org/mailman/listinfo/zope-coders

On Fri, Aug 06, 2004 at 12:31:25PM +0200, Lennart Regebro wrote:
| That in turn means that what is actually missing is a way to distinguish
| between something that has just been submitted, and something that
| somebody has noticed. So I suggest a "submitted" state, as default state
| for new issues, and that we change it to "pending" if we need more info,
| or accept/reject/wontfix.

Roundup calls the initial state 'unread'.

--
Sidnei da Silva <sidnei@awkly.org>
http://awkly.org - dreamcatching :: making your dreams come true
http://www.enfoldsystems.com
http://plone.org/about/team#dreamcatcher

grep me no patterns and I'll tell you no lines.
_______________________________________________
Zope-Coders mailing list
Zope-Coders@zope.org
http://mail.zope.org/mailman/listinfo/zope-coders

Ken Manheimer wrote:
> I wasn't thinking about non-supporter helpers, and wasn't intending to
> suggest excluding them. You're right, it would be good to tell them to
> contact a supporter if they want to help. In fact, this applies whether
> or not the issue is accepted, right?

Well, not really. If the issue hasn't been accepted, no-one has been
assigned, so there's no one person to contact.

> If you intend to work on an issue but are not on the collector staff,
> add a comment to the issue indicating so. You will not be
> able to change the status of the issue, but you can leave remarks about
> how it is settled so some supporter can review and settle it
> accordingly.

How does it look now?

Chris

--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
_______________________________________________
Zope-Coders mailing list
Zope-Coders@zope.org
http://mail.zope.org/mailman/listinfo/zope-coders

Lennart Regebro wrote:
> Oh, and I think "deferred" as saying "this should be fixed but is not
> important" clashes with the Importance field.

Good point. Which is why it doesn't mean that anymore.

It just means the issue has one month to have more information added to
it, or it bites the dust either as a Reject (most often) or as a Wontfix.

Chris

--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
_______________________________________________
Zope-Coders mailing list
Zope-Coders@zope.org
http://mail.zope.org/mailman/listinfo/zope-coders

Chris McDonough wrote:
> at again except as a historical curiosity. I think this may have to do
> with your definition of "wontfix", which differs from mine:

Indeed. The biggest problem really seems to be to get people to use the
same labels for the same thing, hence my attempts at documentation.

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

Agreed. I've removed this bullet point.

> Features that don't have a champion and so are unlikely to be
> implemented.
>
> I would call this "deferred".

yeah, but what does that buy us? A load of issues in a state which
no-one looks at. This is Wontfix for me. Stuff in Wontfix is valid, it
just Wont (be) fix'ed unless someone gets in there and digs it out. AS
isaid to Ken, it's also slightly more provocative than "Deferred" which
tends to float by people and we end up with issues that end up being
fixed, but deferred issues never marked as resolved because no-one knows
they exist ;-)

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

See above paragraph ;-)

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

50 per page ;-) Personally, I set my batch size at 200 and make Zope.org
suffer for running on Plone *grinz* Seriously though, the pattern I see
is people pick off the important issues AS they get submitted. Tricky
but non-critical ones tend to languish in Pending along with the other
flotsam. These get picked off in no particular order as people bump into
them. Stuff that was in Deferred never got touched. So for me, Pending
and Deferred as they were, were the same. Wontfix is a more assertive
way of saying "this ain't gonna happen" without Rejecting it...

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

Maybe next bug day :-/

> If Ken added a pending rejection state, would it be reasonable to use
> that instead of deferred to mean "pending rejection"?

Sure, although it makes me cry that stuff will get slung into either
Wontfix or Deferred with most people not knowing the difference and
neither will ever get looked at :-/

Chris

--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
_______________________________________________
Zope-Coders mailing list
Zope-Coders@zope.org
http://mail.zope.org/mailman/listinfo/zope-coders

Tres Seaver wrote:
>
> The major missing reason for "wontfix" is that the requested change
> breaks something more important than whatever pain / inconvenience /
> itch prompted the request

But that's been in my list for Wontfix since day 1 :-S

Chris

--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
_______________________________________________
Zope-Coders mailing list
Zope-Coders@zope.org
http://mail.zope.org/mailman/listinfo/zope-coders

Ken Manheimer wrote:
> I *really* don't think the "pending rejection" distinction adds value.

It REALLY does on bug days ;-)

It's useful to be able to do "right, this is in pending rejection /
deferred.. when was it put there? over a month ago? okay, it goes...

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

That would also do the trick!

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

This is the problem step. Who does this and when?

I'd prefer stuff to stay in the forefront and get dealt with, one way or
another... I'm doing my best to see that happen with as many issues as
possible...

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

Hear hear! *gripes about CollectorStatusesAlt* ;-)

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

Not to mention just plain inadvertant misuse to to reappropriation of
time :-/

> 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
> sound workable?

What did you propose?

I like the expirey date thing. If something could get auto-pending'ed
from defered after being there for a month or two, that would be great.
I was tempted to say auto-rejected, but that might not be right in all
cases. Then again, it might, what do people think?

Chris

--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
_______________________________________________
Zope-Coders mailing list
Zope-Coders@zope.org
http://mail.zope.org/mailman/listinfo/zope-coders

Ken Manheimer wrote:
> I think what your saying amounts to "stuff in deferred languishes because
> there's so much of it and nobody looks there, so we should move it to
> pending".

It's not really volume. It's more "stuff in deferred languishes because
people put it there, then forget about it / move on, and no-one thinks
to look there, even when they resolve the thing being discussed in the
issue"

> What i think this will accomplish is make it harder to tell the
> difference between stuff that's assessed as being deferrable and stuff
> that's not. Why would you want to do that?

I want to see more issues resolved in a more satisfactory way. Having
stuff dumped into a Deferred state doesn't seem to aid this :-S

>>pending with a comment is how this works in practice...
>
> Evidently not everyone's practice.

No, evidently not everyone's THEORY ;-)

> I think if deferred were understood
> and used the way it should be there would be a gain.

Yeah, maybe, for a while, as long as people have a point to prove and
time to spare. Then it drops back to being an oubliet :-S

> Making things get hidden in Pending, which is worse.

I don't think so, people browse pending, usually from the end backwards.
They may glace at something there which if in Deferred they would never
have done. I know if most of the issues I hauled out of Deferred had
been in Pending, I would have gotten to them months sooner...

> I think if people understood the difference better (thank you for this
> effort to make that happen!) it would work better.

I think that's a nice theory scuppered by the reality of people's
limited time and memory...

Chris - me, cynical? naaah ;-)

--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
_______________________________________________
Zope-Coders mailing list
Zope-Coders@zope.org
http://mail.zope.org/mailman/listinfo/zope-coders