Mailing List Archive

On Sat, 31 Jul 2004, Chris Withers wrote:

> Also, there's now documentation of what the various collector states
> mean at:
>
> http://dev.zope.org/CVS/CollectorStatuses
>
> Some points of it are still up for discussion, so please join in at
> zope-coders@zope.org if you have a view!

I have a pretty different conception of the states. I've created another
page, linked into chris', with my alternate framing, at:

http://dev.zope.org/CVS/CollectorStatusesAlt

Obviously, we need to resolve the differences so all the supporters use
the states the same way. I hardly participate in the zope collector
(though i do use collectors all the time for a lot of projects), so i'll
defer to the people who actually use it - but want to suggest this framing
because i think it'll help reduce the chaos.

> All in all, a massive 64 issues were dealt with!
> Many thanks to all who helped out, look forward to seeing as many of you
> as possible for the next one at the end of August...

Thanks to all for making zope better, and particularly to chris for
shepherding the effort!

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

(bringing this back to zope-coders where it belongs..)

Ken Manheimer wrote:
> Then why were you asking for feedback in the first place?

Well, naturally, I expected everyone to agree with me ;-)

> A few supporters (chris, andreas, and dieter, at least) have indicated

I didn't read Andreas's comments as disagreeing, Chris seems to be on
the samish wavelength, Dieter's comment is worthless without elaboration...

> that they had different interpretations than you did, more similar to what
> i am suggesting. So at the least, the waters were already at least this
> muddy. The question, then, is how to settle on one set of states.

Yeah, agreed :-)

> - Lennert has proposed a "Submitted" state (which i interpret as being
> for issues that are pending disposition), instead of pending
> (i think "Submitted" is an improvement on "Pending")

I think Sidnei's reminder of Roundup's "Unread" state is better yet.

> - and "Pending" would be for items awaiting more info (i think that
> should instead be either "Accepted", if someone is taking
> responsibility, if only to "Reject" the thing if no more info is
> forthcoming, else "Deferred" if nobody is taking responsibility - it
> can go back to "Submitted" if more info comes...

I actually like Pending here. For me, it's Pending something,
acceptance, rejection, who knows? we need more info ;-)
I notice to attach a lot of importance to having someone assigned and
accountable. Is this a reality in an open source development environment?

> - sidnei mentioned that roundup calls the initial state "unread" (but i
> don't think that really applies to our initial state, because things
> may be read but not assigned any handling - and i don't think we need
> a state for truly "unread")

Hmm... I see you point, can't say why, but Unread still feels "right"er
for me :-S

> I guess i think we could make progress talking each state through.

Sure, lets start from the top. What state does stuff go into when it's
first plonked into the collector?

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 Tue, 10 Aug 2004, Chris Withers wrote:

> Ken Manheimer wrote:
> > I guess i think we could make progress talking each state through.
>
> Sure, lets start from the top. What state does stuff go into when it's first
> plonked into the collector?

"Submitted"

This is the state for things that are awaiting handling, as opposed to
being handled or closed/settled.

Issues _can_ return here if they got into a being-handled or closed
state but then lost that progress. Eg, something that was assigned to a
supporter, but then the supporter had to bail out and no other
supporters could take it on. Or something that was mistakenly closed -
and no supporters can take responsibility for it.

That's my candidate for the first state.

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

On Tue, 10 Aug 2004, Ken Manheimer wrote:

> On Tue, 10 Aug 2004, Chris Withers wrote:
>
> > Ken Manheimer wrote:
> > > I guess i think we could make progress talking each state through.
> >
> > Sure, lets start from the top. What state does stuff go into when it's first
> > plonked into the collector?
>
> "Submitted"
>
> This is the state for things that are awaiting handling, as opposed to
> being handled or closed/settled.
>
> Issues _can_ return here if they got into a being-handled or closed
> state but then lost that progress. Eg, something that was assigned to a
> supporter, but then the supporter had to bail out and no other
> supporters could take it on. Or something that was mistakenly closed -
> and no supporters can take responsibility for it.
>
> That's my candidate for the first state.

A conversation with some folks here swayed me to a slightly different
proposal for "Submitted". Instead of replacing "Pending", it would be
only for issues that have not been touched. Comments would move issues to
"Pending", and "Pending" would be where issues return if they are
"unaccepted" moved out of a settled state without having an assigned
supporter.

So i'm up to two states:

"Submitted"

This is the state for things that are completely unhandled. Comments
move "Submitted" issues to "Pending", and once out of "Submitted" issues
generally do not return there. (Until we discover a compelling reason
to recirculate issues back, they don't return here.)

"Pending"

Issues that have been handled (have comments and/or other actions) but
are still awaiting substantial disposition (assignment or settlement).

Issues _can_ return here if they got into a being-handled or closed
state but then lost that progress. Eg, something that was assigned to a
supporter, but then the supporter had to bail out and no other
supporters could take it on. Or something that was mistakenly settled,
but has no supporter to take its responsibility and so has to be
returned to an awaiting-disposition state - "Pending" is it.

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

Ken Manheimer wrote:

> "Submitted"
>
> This is the state for things that are awaiting handling, as opposed to
> being handled or closed/settled.
>
> Issues _can_ return here if they got into a being-handled or closed
> state but then lost that progress.

Surely a closed state is a closed state? The only way I can see
something going from a closed state back to "Submitted" is if a mistake
was made, correct?

> Eg, something that was assigned to a
> supporter, but then the supporter had to bail out and no other
> supporters could take it on. Or something that was mistakenly closed -
> and no supporters can take responsibility for it.
>
> That's my candidate for the first state.

Sounds good to me :-)

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:
> So i'm up to two states:
>
> "Submitted"
>
> This is the state for things that are completely unhandled. Comments
> move "Submitted" issues to "Pending", and once out of "Submitted" issues
> generally do not return there. (Until we discover a compelling reason
> to recirculate issues back, they don't return here.)

Even better! I can't see any reason for issues to return to "Submitted"
given the definition here...

> "Pending"
>
> Issues that have been handled (have comments and/or other actions) but
> are still awaiting substantial disposition (assignment or settlement).
>
> Issues _can_ return here if they got into a being-handled or closed
> state but then lost that progress. Eg, something that was assigned to a
> supporter, but then the supporter had to bail out and no other
> supporters could take it on. Or something that was mistakenly settled,
> but has no supporter to take its responsibility and so has to be
> returned to an awaiting-disposition state - "Pending" is it.

Yep, even better too. Is there any way we could have issues that are in
non-terminal states other that "submitted" be authomatically returned to
Pending if they're been in their current state for longer than 1 month
with no action (ie: comments or state changes) added?

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

On Thu, 12 Aug 2004, Chris Withers wrote:

> Ken Manheimer wrote:
>
> > "Submitted"
> >
> > This is the state for things that are awaiting handling, as opposed to
> > being handled or closed/settled.
> >
> > Issues _can_ return here if they got into a being-handled or closed
> > state but then lost that progress.
>
> Surely a closed state is a closed state? The only way I can see
> something going from a closed state back to "Submitted" is if a mistake
> was made, correct?

Mistaken settlement of an issue is one reason. There are others. In the
real world situations can change in unexpectable ways, making eg
previously unfixable things fixable. (The goal of issue management is not
perfection, but improved collective intelligence in the process of dealing
with problem reports.)

Ken
klm@zope.com

Intelligence: Err
and err,
and err again,
but less
and less
and less. -- Piet Hien ("Grooks")


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

Sounds like nobody objects to "Suspend" and "Pending" as i framed them.
Cool.

Here's three more, leaving the two most controversial (and the idea of
providing for automatic expiration) for later. I'll be out of the office
and away until monday, so will continue my part in the discussion then.
Good weekend, all!

"Assigned" (instead of "Accepted")

Issues that have at least one supporter responsible for their
solution. This is the state for issues that are being worked on or are
awaiting complete assessment for their viability depending on further
input from the submitter.

The assigned supporters are responsible for either solving the issue or
collecting further information to determine what resolution it deserves.

Supporters are assigned to issues either by "accepting" them or via
"assignment" by another supporter or collector manager. Supporters can
resign from the issue, but the issue will automatically move back to
"Pending" if that leaves it with no supporters.

(People interested in helping with the resolution of an accepted issue -
or any issue, for that matter - but lacking official supporter privileges
can signal their intention by posting a comment to the issue.)

"Resolved"

The fix or feature has been implemented, along with any necessary tests.

Tests which would provoke the bug, if it were still present, and/or
demonstrate the correctness of the new functionality are always required,
unless they are impossible to write. (Leniency may be warranted for very
minor changes?)

When you resolve an issue, please include details about:

o the action taken

o the repository branches where code was committed

o the expected Zope version(s) where the changes will land.

"Rejected"

Issues assessed to be invalid for this collector, so that they will not
be addressed any further.

Common reasons for rejection:

o The issue is outside the scope of the collector. For the Zope
collector, this means the issue is not with a central Zope component,
but rather a third-party item such as a database adapter, Plone,
etc. The rejecter should indicate the appropriate venue for the
issue, when known.

o The issue cannot be reproduced. The rejector should establish that
there is a test, if feasible, demonstrating that the reported behaviour
does not occur, writing one if necessary.

o More information was necessary to assess the issue, and it was
requested, but was not provided within a reasonable period (typically
a month).

> "Submitted"
>
> This is the state for things that are completely unhandled. Comments
> move "Submitted" issues to "Pending", and once out of "Submitted" issues
> generally do not return there. (Until we discover a compelling reason
> to recirculate issues back, they don't return here.)
>
> "Pending"
>
> Issues that have been handled (have comments and/or other actions) but
> are still awaiting substantial disposition (assignment or settlement).
>
> Issues _can_ return here if they got into a being-handled or closed
> state but then lost that progress. Eg, something that was assigned to a
> supporter, but then the supporter had to bail out and no other
> supporters could take it on. Or something that was mistakenly settled,
> but has no supporter to take its responsibility and so has to be
> returned to an awaiting-disposition state - "Pending" is it.

Ken
klm@zope.com

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

Ken Manheimer wrote:

> Sounds like nobody objects to "Suspend" and "Pending" as i framed them.
> Cool.

Who the what the? I didn't see them anywhere...
Pending -> fine, Suspend -> even the word makes me nervous ;-)

> "Assigned" (instead of "Accepted")
>
> Issues that have at least one supporter responsible for their
> solution. This is the state for issues that are being worked on or are
> awaiting complete assessment for their viability depending on further
> input from the submitter.
>
> The assigned supporters are responsible for either solving the issue or
> collecting further information to determine what resolution it deserves.
>
> Supporters are assigned to issues either by "accepting" them or via
> "assignment" by another supporter or collector manager. Supporters can
> resign from the issue, but the issue will automatically move back to
> "Pending" if that leaves it with no supporters.
>
> (People interested in helping with the resolution of an accepted issue -
> or any issue, for that matter - but lacking official supporter privileges
> can signal their intention by posting a comment to the issue.)

OK. I still like the idea of assigned stuff going back to pending if no
action happens for a month. Is that a possibility?

> "Resolved"
>
> The fix or feature has been implemented, along with any necessary tests.
>
> Tests which would provoke the bug, if it were still present, and/or
> demonstrate the correctness of the new functionality are always required,
> unless they are impossible to write. (Leniency may be warranted for very
> minor changes?)

...or in situations where ther eare no tests for the whole area the
change is to be made in?

> When you resolve an issue, please include details about:
>
> o the action taken
>
> o the repository branches where code was committed
>
> o the expected Zope version(s) where the changes will land.

Sounds good.

> "Rejected"
>
> Issues assessed to be invalid for this collector, so that they will not
> be addressed any further.
>
> Common reasons for rejection:
>
> o The issue is outside the scope of the collector. For the Zope
> collector, this means the issue is not with a central Zope component,
> but rather a third-party item such as a database adapter, Plone,
> etc. The rejecter should indicate the appropriate venue for the
> issue, when known.
>
> o The issue cannot be reproduced. The rejector should establish that
> there is a test, if feasible, demonstrating that the reported behaviour
> does not occur, writing one if necessary.
>
> o More information was necessary to assess the issue, and it was
> requested, but was not provided within a reasonable period (typically
> a month).

Yep.

>>"Submitted"
>>
>> This is the state for things that are completely unhandled. Comments
>> move "Submitted" issues to "Pending", and once out of "Submitted" issues
>> generally do not return there. (Until we discover a compelling reason
>> to recirculate issues back, they don't return here.)

Can we clear this up? How about:

"Submitted"
This is the state for items that have not been assessed. Comments
move "Submitted" issues to "Pending", and once out of "Submitted"
issues do not return there.

>>"Pending"
>>
>> Issues that have been handled (have comments and/or other actions) but
>> are still awaiting substantial disposition (assignment or settlement).
>>
>> Issues _can_ return here if they got into a being-handled or closed
>> state but then lost that progress. Eg, something that was assigned to a
>> supporter, but then the supporter had to bail out and no other
>> supporters could take it on. Or something that was mistakenly settled,
>> but has no supporter to take its responsibility and so has to be
>> returned to an awaiting-disposition state - "Pending" is it.

Sounds good.

Still waiting to see what this scarey "Suspend" state is, I'm hoping it
was a typo :-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:
> "Rejected"
>
> Issues assessed to be invalid for this collector, so that they will not
> be addressed any further.
>
> Common reasons for rejection:

I'd like to add one here:

o Duplicate issues.

...unless we can add Duplicate functionality like the original collector
had ;-)

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

On Fri, 13 Aug 2004, Chris Withers wrote:

> Ken Manheimer wrote:
>
> > Sounds like nobody objects to "Suspend" and "Pending" as i framed them.
> > Cool.
>
> Who the what the? I didn't see them anywhere...
> Pending -> fine, Suspend -> even the word makes me nervous ;-)

Whoops - "Submitted" (as lennart proposed, and i included in my first
batch in this thread), not "Suspend".

> [...]
> >>"Submitted"
> >>
> >> This is the state for things that are completely unhandled. Comments
> >> move "Submitted" issues to "Pending", and once out of "Submitted" issues
> >> generally do not return there. (Until we discover a compelling reason
> >> to recirculate issues back, they don't return here.)
>
> Can we clear this up? How about:
>
> "Submitted"
> This is the state for items that have not been assessed. Comments
> move "Submitted" issues to "Pending", and once out of "Submitted"
> issues do not return there.

Fine. I might even add a bit more clarification:

"Submitted"
This is the state for items that have not been touched by a
supporter. Any action moves issues out of the Submitted state, and
once out issues do not return there. Comments move "Submitted" issues
to "Pending".

> [...]
> Still waiting to see what this scarey "Suspend" state is, I'm hoping it
> was a typo :-S

Or, as i like to say, a typoo.

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

Chris Withers wrote:

> OK. I still like the idea of assigned stuff going back to pending if no
> action happens for a month. Is that a possibility?

I would rather address the issue with "nagmail": each supporter would
get a periodic (weekly, likely, for the main Zope collector) e-mail
summarizing the issues to which they are assigned.

>> "Resolved"
>>
>> The fix or feature has been implemented, along with any necessary
>> tests.
>>
>> Tests which would provoke the bug, if it were still present, and/or
>> demonstrate the correctness of the new functionality are always
>> required,
>> unless they are impossible to write. (Leniency may be warranted for
>> very
>> minor changes?)
>
>
> ...or in situations where ther eare no tests for the whole area the
> change is to be made in?

Nope. *Any* change could be expected to have one or more tests which
demonstrate either that:

- the bug existed before before the fix (e.g., the test fails without
the fix), but no longer exists after (the test passes).

- the new feature works.

Writing more tests for the unit being changed qualifies as a "work of
supererogation." There are occoasionally areas (medusa's guts, for one)
which are so gnarly that nobody can figure out how to write tests for
that. If you plan to resolve an issue without adding test, and want to
plead "gnarliness" as an excuse, expect to defend the choice. ;)

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

Chris Withers wrote:

> OK. I still like the idea of assigned stuff going back to pending if no
> action happens for a month. Is that a possibility?

I would rather address the issue with "nagmail": each supporter would
get a periodic (weekly, likely, for the main Zope collector) e-mail
summarizing the issues to which they are assigned.

>> "Resolved"
>>
>> The fix or feature has been implemented, along with any necessary
>> tests.
>>
>> Tests which would provoke the bug, if it were still present, and/or
>> demonstrate the correctness of the new functionality are always
>> required,
>> unless they are impossible to write. (Leniency may be warranted for
>> very
>> minor changes?)
>
>
> ...or in situations where ther eare no tests for the whole area the
> change is to be made in?

Nope. *Any* change could be expected to have one or more tests which
demonstrate either that:

- the bug existed before before the fix (e.g., the test fails without
the fix), but no longer exists after (the test passes).

- the new feature works.

Writing more tests for the unit being changed qualifies as a "work of
supererogation." There are occoasionally areas (medusa's guts, for one)
which are so gnarly that nobody can figure out how to write tests for
that. If you plan to resolve an issue without adding test, and want to
plead "gnarliness" as an excuse, expect to defend the choice. ;)

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, Aug 13, 2004 at 10:42:09AM -0400, Tres Seaver wrote:
> Writing more tests for the unit being changed qualifies as a "work of
> supererogation." There are occoasionally areas (medusa's guts, for one)
> which are so gnarly that nobody can figure out how to write tests for
> that. If you plan to resolve an issue without adding test, and want to
> plead "gnarliness" as an excuse, expect to defend the choice. ;)

Supererogation, great word.

Some day I must learn the fine art of picking bugs for bug day that
don't lead me down the path of struggling to get the first no-op testcase
to *run* in some previously-untested area, before i can get any
real work done...
"This little bug looks pretty easy to fix... DOH!"
:-\

--

Paul Winkler
http://www.slinkp.com
_______________________________________________
Zope-Coders mailing list
Zope-Coders@zope.org
http://mail.zope.org/mailman/listinfo/zope-coders

Ken Manheimer wrote:
> "Submitted"
> This is the state for items that have not been touched by a
> supporter. Any action moves issues out of the Submitted state, and
> once out issues do not return there. Comments move "Submitted" issues
> to "Pending".

Sounds good to me :-)

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:

> I would rather address the issue with "nagmail": each supporter would
> get a periodic (weekly, likely, for the main Zope collector) e-mail
> summarizing the issues to which they are assigned.

I'm all for both. nagmail is great for annoying^wreminding the
supporter, but it doesn't bring issues back into the
pool-that-need-to-be-dealt-with (I believe "Pending" is the agreed term
for this now) so other people can deal with them once the supporter has
changed their email address or learned how to filter out the nagmail ;-)
(FWIW, I think every single issue that had been dumped in "Deferred" was
assigned to someone who had since changed their email address...)

> Nope. *Any* change could be expected to have one or more tests which
> demonstrate either that:
>
> - the bug existed before before the fix (e.g., the test fails without
> the fix), but no longer exists after (the test passes).
>
> - the new feature works.

Okay, but big areas where there are no tests may see less attention as a
result. I know this is a horrible chicken and egg situation :-S

> Writing more tests for the unit being changed qualifies as a "work of
> supererogation."

And in english? ;-)

> There are occoasionally areas (medusa's guts, for one)
> which are so gnarly that nobody can figure out how to write tests for
> that. If you plan to resolve an issue without adding test, and want to
> plead "gnarliness" as an excuse, expect to defend the choice. ;)

Hehe, okay, that sounds fair enough :-)

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:

>> Writing more tests for the unit being changed qualifies as a "work of
>> supererogation."
>
>
> And in english? ;-)

Check the Articles of Religion in your Book of Common Prayer.

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:
>> And in english? ;-)
>
> Check the Articles of Religion in your Book of Common Prayer.

I'm afraid I don't have access to such a tome :-/

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 Tue, 17 Aug 2004 08:54:18 +0200
Chris Withers <chris@simplistix.co.uk> wrote:
> Tres Seaver wrote:
> >> And in english? ;-)
> >
> > Check the Articles of Religion in your Book of Common
> Prayer.
>
> I'm afraid I don't have access to such a tome :-/

Your Parliament still has to approve changes to it ;)

http://www.eskimo.com/~lhowell/bcp1662/index.html

and in particular:

http://www.eskimo.com/~lhowell/bcp1662/articles/articles.html

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:
> Your Parliament still has to approve changes to it ;)

You talking about the Irish or the English?

> and in particular:
>
> http://www.eskimo.com/~lhowell/bcp1662/articles/articles.html

http://www.eskimo.com/~lhowell/bcp1662/articles/articles.html#14

I think I understand this now having read everythign in context: don't
write more tests than you need to, right?

Hmmm...

Chris - http://www.eskimo.com/~lhowell/bcp1662/articles/articles.html#33

--
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:
>
>> Your Parliament still has to approve changes to it ;)
>
>
> You talking about the Irish or the English?
>
>> and in particular:
>>
>> http://www.eskimo.com/~lhowell/bcp1662/articles/articles.html
>
>
> http://www.eskimo.com/~lhowell/bcp1662/articles/articles.html#14
>
> I think I understand this now having read everythign in context: don't
> write more tests than you need to, right?

Nope. The A of R says that claiming extra "stars in your crown" for
going above-and-beyond the law is bogus; it also says that the Church
may not teach / compel people to do such things.

Nailing-theses-to-the-door'ly,

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