Hi Roel and all!

Roel Wuyts <roel.wuyts at iam.unibe.ch> wrote:
> >> But we never had problem with that.
> >
> > Good. :-)
> >
> > No, but seriously - I just got the impression that... well, this can 
> > get
> > hard to express in a non-native language. Hmmm. It sounded to me that 
> > if
> > Squeak as a community "wouldn't do this and that" then you would simply
> > leave and pick another Smalltalk.
> 
> [Let's try to reply properly in our non-native English :-) ]
> 
> Kind of, but not that black-white really. We are just evaluating what 
> we need for a second-step traits (and Classboxes, our module work, and 
> some even newer things). Like Stef said, certain infrastructure should 
> be tackled, and we are willing to help with this, invest time there, 
> and take some responsibility. So it's not that we expect the community 
> to do lots of things and that then we would bless/curse them with 
> something like traits :-) We expect to do a lot of the work there 
> -which is not a problem- but something will have to come from the 
> community: playing with these things, with a minimum of documentation, 
> providing feedback, and helping out. I'd like to take the StarBrowser 

This all sounds good to me.

> as an example (although it is not completely what we have in mind). I 
> just did an initial port with minimum functionality, and Ned took over 
> from there. This was good because that way the browser is taken up by 
> the community (at least by one member :-) ). It was not good that I was 
> not able to help Ned much - I couldn't catch up with him once he 
> started :-) The reason is that the StarBrowser is my late-night fun 

Ned is fast. :-)

> project, not research work for which I have proper time during the day. 
> So for traits, the parser, browser, ... etc. I think a likewise 
> approach should work, but we will be able to invest much more time in 
> it and drive the initial effort.

Right.

> So, in short, we want to do some core work to the language (since we 
> need it anyway) and want to provide the results back to the community). 

> But we are a bit afraid that such effort would not be taken in easily. 
> Again, initially this will have rough edges and no documentation.

These two last lines are then the interesting part to discuss further.
A few off the head remarks:

- I have a hard time seeing anyone objecting to general improvement. :-)

- Experimental stuff should of course be kept in non-core SM packages
until matured. Again, this other issue needs discussion. In any way the
modular future should make it easier to handle these "controversial"
changes because it will not be a black/white thing (you get into the
image or not).

- We are talking about major contributions here and we can surely adapt
and make some targetted effort for them. (The current harvesting process
is limping but we are trying to get a handle on that - but it will take
a while)

So I don't think you need to be afraid of getting good stuff "accepted".
:-)

Instead you *should* be afraid of the fact that there will be few people
around to help you out. We (he, not implying that I count myself into
this group) aren't that many that can tackle these areas and those that
can may not have much time to offer. So you need to do some serious
"marketing" and "community tending" to drum up the adrenalin and get
that help. Anthony, Daniel and Andreas are obvious targets for this
stuff - but there are of course a few more people out there that can
"wield the magic of meta classes". But not *that* many.

[SNIP]
> > Finally - I am confident we will make the best of this all. We just 
> > need
> > to start thinking in terms of how to manage the cooperation in the
> > community. Earlier this was not a "problem" because we more or less had
> > a benevolent dictatorship (SqC). Now when we are moving over into a
> > community shared mode with distributed "ownership" of packages etc, the
> > "tending" of the community turns into a much more complex job.
> >
> > And given this I would like us to formulate - as a start - these 
> > package
> > groups I was talking about and how they should be allowed to depend on
> > each other. This will give us a "planning table" where we can place the
> > packages and see how they should/would/could relate to each other.
> >
> > I think I need to fire up that issue again in another thread. It was a
> > mistake to put both in the same thread. ;-)
> 
> Then I'll wait for your mail there :-)

Ok, give me a few hours - or you could start it yourself of course :-) -
I need to do some Dolphin here. It is a *really* important discussion I
think and we need to get cracking in that area.

regards, Göran