Hi All, Apologies for the cross-posting, but I think this is relevent to all these lists. 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 ;-) The only real change is that Deferred now means "we asked the user for more information and we'll reject the issue unless they give it to us within a month" I went through all the issues which WERE deferred and "dealt" with them. I'm trying to avoid having states where issues end up that aren't definitive and so get forgotten about. The "wontfix" stuff now has a definitve meaning, but it may still be good to go through them all once a year or so to check that none of them have been solved in other ways. I found quite a few of the "deferred" ones that really should have been "wontfix" had been addressed and could now be marked as resolved :-) cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
I would put my $0.02 for a 'tested' state, entered from Resolved. So from resolved you could 'resubmit' back to pending or accepted, or go to tested. This because it does happen, that someone *thinks* they have fixed something, but didn't test it thoroughly (there are usually way to many combinations for one person to do so), and it wasn't really fixed. On Friday, July 30, 2004, at 10:01 AM, Chris Withers wrote:
Hi All,
Apologies for the cross-posting, but I think this is relevent to all these lists.
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 ;-)
The only real change is that Deferred now means "we asked the user for more information and we'll reject the issue unless they give it to us within a month"
I went through all the issues which WERE deferred and "dealt" with them. I'm trying to avoid having states where issues end up that aren't definitive and so get forgotten about.
The "wontfix" stuff now has a definitve meaning, but it may still be good to go through them all once a year or so to check that none of them have been solved in other ways. I found quite a few of the "deferred" ones that really should have been "wontfix" had been addressed and could now be marked as resolved :-)
cheers,
Chris
-- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk _______________________________________________ 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 )
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.)
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. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> Zope Corporation
Oh, and I think "deferred" as saying "this should be fixed but is not important" clashes with the Importance field.
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 )
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...
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.
Ken Manheimer wrote at 2004-7-30 11:50 -0400:
On Fri, 30 Jul 2004, Chris Withers wrote: ... My intent for the states is different from what you suggested, in some cases significantly.
I like your intents! -- Dieter
Dieter Maurer wrote:
Ken Manheimer wrote at 2004-7-30 11:50 -0400:
On Fri, 30 Jul 2004, Chris Withers wrote: ... My intent for the states is different from what you suggested, in some cases significantly.
I like your intents!
Can you explain what bits specifically? This comment currently doesn't aid anything ;-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
participants (8)
-
Chris McDonough -
Chris Withers -
Dieter Maurer -
Fred Drake -
Ken Manheimer -
Lennart Regebro -
Marc Lindahl -
Sidnei da Silva