I have little time but I am a Software Architect.
So if you (=the community/board directors)  like I can draw some
guidelines for the SqueakCore project.
For instance we can draw together some basic rules for API
deprecation, unit testing and so on.
Drop me an email  :-)
My 4 cents (yes I am a bit more  rich :)


On 8/26/06, Milan Zimmermann <milan.zimmermann at sympatico.ca> wrote:
[...]
>
> Yes that makes sense. I felt uneasy commenting on this given I am barely a
> weekend squeaker, but got encouraged by the original question "what would it
> take for you[squeak-dev list member] to "buy in" to a central governance
> model for Squeak".
>
> >
> > Also, Squeak would continue to evolve the Squeak we know.  Discussions
> > about tossing it and starting from the ground up are interesting but
> > off topic.  If you want to do that, then you are free, but Squeak's
> > organization should take care of Squeak.
>
> What I had intuitively in mind (by saying it would make sense to encourage
> alternative cores) would be their existence would show the API to the core is
> well-defined and hopefully stable. In a way similar to ability to run (a
> large set of) packages such as KDE on both Linux and FreeBSD shows there must
> be well-understood API to the cores (perhaps with different adapters but
> still defined).  Apart from that clarification I agree talking about
> alternatives was off-topic.
>
> Milan



-- 
Software Architect
http://www.objectsroot.com/
Software is nothing