>Dan's process reminds me somewhat of the Scheme SRFI (Scheme Request For
>Implementation) process - http://srfi.schemers.org/ . While I consider
>the actual SRFI process much too rigid and formal for our purposes, I do
>like how it focuses each SRFI on a particular item or closely related
>group of items [...]

I like the idea to establish this or a similar process for Squeak.  Dwight,
it you think, SRFI is too formal, what kind of process do you have in mind?

I'd like to see both a recommendation of how to submit entries (kind of a
check list of heading you need to fill out or questions you have to answer
and topics you have to cover) and a process that describes how to submit,
to modify and eventually agree upon the entries.  The should also define
the time frame between submission and acceptance (or rejection) and how the
decision is made (by voting, by the word of SqC, by duelling, ...) 

Or as Dan wrote...

>> Here is a proposal for getting it done:
>> 
>> 1)  Some brave soul or (as we used to say in the 60's) affinity group
steps forward to draft a spec for better Symbol and Array printOn: (and
whatever not-too-vast set of other things that should accompany them).

So stepping forward is how to submit an entry.

>> 2)  We (all Squeakies) bless this, and someone implements it.

So blessing (what ever that mean - how do I send holy water via email ;-)
to how to do the decision.

>> 3)  It then gets circulated for review and test as a fileIn (not an
update).

So the time frame is very vague - say until most people lose interest.  I'd
prefer to have a better defined time frame, lets say 4 weeks.

>> 4)  We beat on it for a week, and report/fix bugs as usual.

As I understand this, this is after agreement, to iron out bugs, right?

>> 5)  As soon as it looks reasonable, I'll put it out as an update for
2.8alpha, where it will get lots more testing before 2.8 is done.

>> Does this sound like an effective approach?

I think so (with the above exception).


bye
--
Stefan Matthias Aust  //  Bevor wir fallen, fallen wir lieber auf.