Mailing List Archive

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-Coders mailing list
Zope-Coders@zope.org
http://mail.zope.org/mailman/listinfo/zope-coders

Ken Manheimer wrote:
> 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.

Yep, I agree with this, sorry clumsy wording on my part. How does the
current version looked?

> 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 see any difference in meaning here, other than sentence
structure. I think I split things because sometimes someone will assign
themselves, and then do nothing on the issue for several years ;-)

> Rejected: Issues that are settled as being somehow invalid or outside
> the scope of the system the collector serves.

I think we agree here too...

> Resolved: Issues that are settled as having been solved.

Indeed. But issues are rejected unless they require chanes to the Zope
core. My notes are meant to ensure people put in appropriate messages
when the yresolve issues.

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

But this is a trap! All it means is that issues get burried and never
looked at again, whether they're resolved or not. As I said, I'm
explicitly changing the meaning of this state rather than adding a new
one because:

1. This state is useless in terms of what it achieves, as-is ;-)
Witness all the activity today from me going through the deferred
issues, most of which had been that way for in excess of a year!

2. Andreas and I need a state which says "this issue is on last warning"
once we've asked people for more info, so we can easilly come back in
a months time and find all said issues and reject them unless people
have provided the required information.

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

I've tightened this a bit, 'cos I don't want people using wontfix as the
bin they abused deferred for ;-)

I'd prefer to have long-standing pending issues rather than forgotten
wontfix'ers...

Lemme know what you 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

On Fri, 30 Jul 2004, Chris Withers wrote:

> Ken Manheimer wrote:
> > 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.
>
> Yep, I agree with this, sorry clumsy wording on my part. How does the
> current version looked?

Not right. An issue may have been processed to hell and back and then
wound up back in pending - eg, someone may have taken responsibility for
it and then realized they couldn't do it, and found noone else to assign
to it. The point is that it is awaiting disposition. You can add
something about the fact that there can be a bunch of history associated
with it (from prior "processing"), and information added while still in
pending.

> > 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 see any difference in meaning here, other than sentence
> structure. I think I split things because sometimes someone will assign
> themselves, and then do nothing on the issue for several years ;-)

See my message to fred. The essential thing, as far as i'm concerned, is
that acceptance fundamentally entails having someone responsible for the
issue. Your framing obscures this. (I gather, from the message of
fred's to which i am responding, that this point is not so obvious, and
understanding it can help people understand the collector workflow.)

> > Rejected: Issues that are settled as being somehow invalid or outside
> > the scope of the system the collector serves.
>
> I think we agree here too...

I would rephrase it, but include the additional exposition.

> > Resolved: Issues that are settled as having been solved.
>
> Indeed. But issues are rejected unless they require chanes to the Zope
> core. My notes are meant to ensure people put in appropriate messages
> when the yresolve issues.

Maybe i should have said "Relevant issues that are settled...". I like
having your prods to include relevant information/tests/etc.

> > 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.
>
> But this is a trap! All it means is that issues get burried and never
> looked at again, whether they're resolved or not. As I said, I'm
> explicitly changing the meaning of this state rather than adding a new
> one because:

As i mentioned in my response to fred, the alternative is either to leave
it pending, where it can obscure other truly pending issues, or mark it as
accepted without a responsible party, which i think can nullify the
usefulness of the collector. I agree with chris, deferred can languish,
but at least there's a clue about that danger.

> 1. This state is useless in terms of what it achieves, as-is ;-)
> Witness all the activity today from me going through the deferred
> issues, most of which had been that way for in excess of a year!

I can see keeping things in pending if they need doing and are awaiting
someone available to take responsibility, and putting things in deferred
that either aren't so needed but would be worth doing, provided resource
availability, or are awaiting further input. I would rather not see
pending cluttered with either of those.

> 2. Andreas and I need a state which says "this issue is on last warning"
> once we've asked people for more info, so we can easilly come back in
> a months time and find all said issues and reject them unless people
> have provided the required information.

Deferred doesn't preclude using it for that. Ideally, the collector would
have provide some "revisit" date (maybe it would promote the issue back to
pending on that date).

> > 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.)
>
> I've tightened this a bit, 'cos I don't want people using wontfix as the
> bin they abused deferred for ;-)
>
> I'd prefer to have long-standing pending issues rather than forgotten
> wontfix'ers...

I think you mean "forgotten deferred's". And obviously, i don't agree
about the abuse of deferred.

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

>From the practical point of view I don't like the fact that some issues
were changed from wontfix to pending
just because the issue may be right and because some volunteer should fix
an issue some time in the future.
When I mark something as wontfix then I will not come across this issue
over and over again in the future
while walking through the collector searching for issues to be fixed. You
start to re-read the same issues
over and over again although you might have thought the issue in the past
and maybe added some comments
on the issue. I would like to have *something* to distinguish between real
pending (new) issues and issues that
are unlikely to be fixed (just because there is some code that anyone won't
touch). Maybe we need a new state
you_are_right_but_we_will_not_fix_this_except_you_fix_it_yourself.

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

Andreas Jung wrote:
>
>> From the practical point of view I don't like the fact that some issues
>
> were changed from wontfix to pending
> just because the issue may be right and because some volunteer should
> fix an issue some time in the future.
> When I mark something as wontfix then I will not come across this issue
> over and over again in the future
> while walking through the collector searching for issues to be fixed.
> You start to re-read the same issues
> over and over again although you might have thought the issue in the
> past and maybe added some comments
> on the issue. I would like to have *something* to distinguish between
> real pending (new) issues and issues that
> are unlikely to be fixed (just because there is some code that anyone
> won't touch). Maybe we need a new state
> you_are_right_but_we_will_not_fix_this_except_you_fix_it_yourself.

That is effectively the meaning of "deferred". "Wontfix" means (to me,
anyway) that the requested change, while addressing a legitimate
problem, would cause more damage than good. "Deferred" means that
somebody looked at it, didn't reject it as invalid, didn't judge that it
was a "wontfix" issue, but that nobody was available to work on it.

I undid a couple of Friday's "wontfix" changes on this basis (one I
rejected, beacuse it was really a Python issue; the other I left
pending, with a patch).

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

(apologies for "going cold" on this, "work" intervened :-S)

Ken Manheimer wrote:
> Not right. An issue may have been processed to hell and back and then
> wound up back in pending - eg, someone may have taken responsibility for
> it and then realized they couldn't do it, and found noone else to assign
> to it.

Ah okay, yeah, good point. How does it look now?

I have to say though, a lot of the time you see issues which were
assigned ages (months to years ago) and have had no further action
since. Is that an acceptable position for an issue to be in?

>>> Accepted: Issues that some supporter(s) has responsibility for resolving
>>> it, and it is not yet resolved.
>
> See my message to fred. The essential thing, as far as i'm concerned, is
> that acceptance fundamentally entails having someone responsible for the
> issue. Your framing obscures this.

How about now? I don't think I've changed anything but it doesn't seem
obscure to me: "Accepted issues will have an assigned supporter"
The problem with responsibility is that currently, anyone who can accept
an issue can ssign it to someone whether they want it assigned to them
or not, this means the assigned person HASN'T necessarily accepted
responsibility... I think the current wording is clear, please explain
what doesn't spear to be :-)

>>> Rejected: Issues that are settled as being somehow invalid or outside
>>> the scope of the system the collector serves.
>>
>>I think we agree here too...
>
> I would rephrase it, but include the additional exposition.

Sorry, what additional exposition? How would you rephrase it?

>>> Resolved: Issues that are settled as having been solved.
>>
>>Indeed. But issues are rejected unless they require chanes to the Zope
>>core. My notes are meant to ensure people put in appropriate messages
>>when the yresolve issues.
>
> Maybe i should have said "Relevant issues that are settled...".

I'm still missing the salient point here, can you explain for the
hard-or-understanding?

> As i mentioned in my response to fred, the alternative is either to leave
> it pending, where it can obscure other truly pending issues,

What's the difference between a "truly pending" issue and a "pending
through no action" item?

> or mark it as
> accepted without a responsible party, which i think can nullify the
> usefulness of the collector.

Well, this would have the meaning people are looking for from Deferred.
I personally agree with you that Accepted should mean someone has signed
up to do the work.

> I agree with chris, deferred can languish,
> but at least there's a clue about that danger.

What's the clue? It happens on every single issue tracking system I've
used which has something akin to a deferred state ;-)

> I can see keeping things in pending if they need doing and are awaiting
> someone available to take responsibility, and putting things in deferred
> that either aren't so needed but would be worth doing, provided resource
> availability, or are awaiting further input.

Well, we need a new state then ;-) But I'll add something about that
later ;-)

> I would rather not see
> pending cluttered with either of those.

I would rather see issues dealt with rather than swept under a carpet a
carpet or dumped into an oubliet. Deferred was both of those things,
Wontfix is a definite: nothing happens here unless someone picks it up.

How about another state: NeedsResource, for what you're currently
wanting Deferred for?

> Deferred doesn't preclude using it for that.

Yes, but having lots of crap in that state which doesn't have a death
penalty over it does...

> Ideally, the collector would
> have provide some "revisit" date (maybe it would promote the issue back to
> pending on that date).

How likely is this to happen? I'd assert it as unlikely, and so I'd like
to use the states as we did at the last bug day...

>>I'd prefer to have long-standing pending issues rather than forgotten
>>wontfix'ers...
>
> I think you mean "forgotten deferred's". And obviously, i don't agree
> about the abuse of deferred.

Nope, I mean if we use Wontfix as you describe, it becomes a deferred
bin. I'd prefer wontfix to be a bin that people delve into when they've
just out of paint to watch dry ;-)

Anyway, just to summarive:

I really truly positively don't any states that can be abused as
deferred has been in the past.

I'm pretty positively against having any more than the current number of
states. KISS and all that, too many states just makes these discussions
more complicated...

on with the rest of the thread...

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

(damn, Andreas is on holiday so we'll have to wait an age for the reply...)

Andreas Jung wrote:
> From the practical point of view I don't like the fact that some issues
> were changed from wontfix to pending

Was that me? I wasn't aware of doing that...

> just because the issue may be right and because some volunteer should
> fix an issue some time in the future.

Wel, if it's a BUG, then I think Pending is right. If it's a feature
request, then yeah, Wontfix it an someone can have a play if they get
bored...

> When I mark something as wontfix then I will not come across this issue
> over and over again in the future
> while walking through the collector searching for issues to be fixed.
> You start to re-read the same issues
> over and over again although you might have thought the issue in the
> past and maybe added some comments
> on the issue. I would like to have *something* to distinguish between
> real pending (new) issues and issues that
> are unlikely to be fixed (just because there is some code that anyone
> won't touch). Maybe we need a new state
> you_are_right_but_we_will_not_fix_this_except_you_fix_it_yourself.

Hmmm, this is Wontfix for me, why is it not?

cheers,

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:
>
> That is effectively the meaning of "deferred".

The only use I saw was "I wanna work on this sometime, so I'm doing to
accept it." Then it gets deferred the next day and never touched again.

"Wontfix" means (to me,
> anyway) that the requested change, while addressing a legitimate
> problem, would cause more damage than good.

I think I covered this with:

- Changes that would be sensible to make, but would impact on
backwards compatability in a way that's not acceptable.

Should I tweak that to:

- Changes that would be sensible to make, but would cause more
damage than good.

?

> "Deferred" means that
> somebody looked at it, didn't reject it as invalid, didn't judge that it
> was a "wontfix" issue, but that nobody was available to work on it.

That's also a Wontfix for me. Because in all practical terms, it means
it won't get fixed, unless someone gets bored or has a point to prove
and drags it out... Wontfix'ing something is also usually provokative
enough that if someone sees something being Wontfix'ed on ZCM and the
ydon't like it, they step in and do something.

Deferred wasn't a powerful enough message to tempt that to happen, but
just resulted in the issues beign forgotten about.

> I undid a couple of Friday's "wontfix" changes on this basis (one I
> rejected, beacuse it was really a Python issue; the other I left
> pending, with a patch).

Well, both of those fall into my definition of Wontfix. The patch is
cute, but if no-one had stepped up, it wouldn't have mattered. The other
one, well, Wontfix and Reject are both "end states" for me, so either
has the same effect ;-)

cheers,

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 Withers wrote:
> Tres Seaver wrote:
>
>>
>> That is effectively the meaning of "deferred".
>
>
> The only use I saw was "I wanna work on this sometime, so I'm doing to
> accept it." Then it gets deferred the next day and never touched again.
>
> "Wontfix" means (to me,
>
>> anyway) that the requested change, while addressing a legitimate
>> problem, would cause more damage than good.
>
>
> I think I covered this with:
>
> - Changes that would be sensible to make, but would impact on
> backwards compatability in a way that's not acceptable.
>
> Should I tweak that to:
>
> - Changes that would be sensible to make, but would cause more
> damage than good.
>
> ?

You could elaborate ( 'e.g., would break backward compatibility, would
make testing hard / impossible, etc.').

> > "Deferred" means that
>
>> somebody looked at it, didn't reject it as invalid, didn't judge that
>> it was a "wontfix" issue, but that nobody was available to work on it.
>
>
> That's also a Wontfix for me. Because in all practical terms, it means
> it won't get fixed, unless someone gets bored or has a point to prove
> and drags it out... Wontfix'ing something is also usually provokative
> enough that if someone sees something being Wontfix'ed on ZCM and the
> ydon't like it, they step in and do something.

You can't argue from "this is how we have behaved" to "this is what it
should mean". "Wontfix" should be an intentionally *permanent* state;
"deferred" means exactly what it says: "later". It exists deliberately
to allow distinguishing between "never looked at" and "passes at least
initial muster".

> Deferred wasn't a powerful enough message to tempt that to happen, but
> just resulted in the issues beign forgotten about.

So work on fixing that, instead of hiding the dirt under a different rug.

>> I undid a couple of Friday's "wontfix" changes on this basis (one I
>> rejected, beacuse it was really a Python issue; the other I left
>> pending, with a patch).
>
>
> Well, both of those fall into my definition of Wontfix. The patch is
> cute, but if no-one had stepped up, it wouldn't have mattered. The other
> one, well, Wontfix and Reject are both "end states" for me, so either
> has the same effect ;-)

Nope, neither fits "wontfix".

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

Tres Seaver wrote:
>> - Changes that would be sensible to make, but would cause more
>> damage than good.
>>
> You could elaborate ( 'e.g., would break backward compatibility, would
> make testing hard / impossible, etc.').

How does the current version look?

>> That's also a Wontfix for me. Because in all practical terms, it means
>> it won't get fixed, unless someone gets bored or has a point to prove
>> and drags it out... Wontfix'ing something is also usually provokative
>> enough that if someone sees something being Wontfix'ed on ZCM and the
>> ydon't like it, they step in and do something.
>
> You can't argue from "this is how we have behaved" to "this is what it
> should mean".

Not sure I follow you...

> "Wontfix" should be an intentionally *permanent* state;

Says / said who? ;-)

> "deferred" means exactly what it says: "later".

Yeah, "no action in a month, this gets booted" ;-)

> It exists deliberately
> to allow distinguishing between "never looked at" and "passes at least
> initial muster".

All I see this doing is obscuring issues from the casual browser who
glances through the pending list...

> So work on fixing that, instead of hiding the dirt under a different rug.

I'm trying to get as few a rugs as possible. I'd like Wontfix to be the
generic rug, and have Deferred be used for something we need in the
absence of new Collector functionality: an indication that an issue is
on it's last warning...

>> Well, both of those fall into my definition of Wontfix. The patch is
>> cute, but if no-one had stepped up, it wouldn't have mattered. The
>> other one, well, Wontfix and Reject are both "end states" for me, so
>> either has the same effect ;-)
>
> Nope, neither fits "wontfix".

It appears we disagree ;-)

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

Another thing which I don't think should be implemented now, but which I
think is a good idea is "reasons" instead of state.

So instead of having one state for every reason not to do anything more
with a bug, you have only one state: Closed, and a *reason* for why it
is closed.

It simplifies things a whole lot.

Then you can close it because "No feedback from user", "Is not a bug",
"fixed" or "will not fix", and so on.

To much change for teh benefit in this case, but maybe something to
think about if the collector gets rewritten in Zope3 or something in the
future.


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

Lennart Regebro wrote:
> So instead of having one state for every reason not to do anything more
> with a bug, you have only one state: Closed, and a *reason* for why it
> is closed.
>
> It simplifies things a whole lot.
>
> Then you can close it because "No feedback from user", "Is not a bug",
> "fixed" or "will not fix", and so on.

Not really. We currently have indicitive end states with reasoning put
in as comments. I think that's the right thing to do.

cheers,

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