Daniel,

> Linux is a platform.
[...]
> Squeak is a platform too.

Ah, now we're slowly getting to the heart of the matter. Which is: What
_kind_ of platform are we talking about? If we take Linux for example, being
an operating system it doesn't make a lot of sense to ship it without file
system support, does it? Being an operating system it makes sense to think
about some integrated services (for example mapping certain things to file
descriptors) and not others. What means are used for the integration hardly
ever matters for the end-user of that platform (and I'm sure there are
uglier parts in the Linux kernel too).

So my question is: What kind of platform is Squeak? If it is a media
platform it doesn't make a lot of sense to ship it without support for fonts
(to take an obvious example) without support for graphics (bitmap, vector or
3D) without support for sound, movies, scripting etc. etc. etc.

> It can be anything you guys want it to be. If
> the core remains maintainable, and easy to build on.

Yeah, or alternatively just buy a piece of hardware and have it everything
you want it to be. For our average user probably the same level of effort
;-)

[... snip ...]
> For things that go into the image, that will affect everything that
> Squeak is to everyone, they would be wise to get some 
> discussion first.

I didn't argue against these discussions. In fact, I think they are very
worthwhile. But guidance is needed for the people who want to do things and
the only entity in place to give that guidance are the guides. Whether you
want it or not - you _have_ this responsibility, you took it on as you
accepted the keys. Welcome to the real world...

> Yes. And we will not manage their project, or push their goal
> forward for them. No. Unless it is something as important as
> multilingualization, in which case we might push it a little, yes.

Ah, okay so some exceptions are made. Has it ever been made clear to the
people who want to do stuff when exactly these exceptions are made? This is
what I meant with "being on the critical path" of Squeak development. If it
can't be made clear what priority a project has within the guides then
people will be left with a lot of uncertainty about what's going to happen
with "their" stuff. For example, is KCP on the critical path? MCP? SM 1.1?
What else?

> It doesn't have to be forgotten, but I see no reason why it's 
> expected that it be remembered by the the Guides.

It's because you are actively participating in the discussions, because you
are soliciting proposals to be brought up. For example: I just posted seven
packages which are hosted at SM for inclusion in the Squeak image. I did
this because you were explicitly asking me to "let you know".

That's the reason why I expect it to be remembered - because you _asked_ for
it.

> > Finally (because I'm just at some larger issues) consider 
> > dropping the "micro management" approach for larger projects.
>
> I agree. But there is no "micro management approach" in place. We are
> establishing understanding slowly. KCP sent some changes, I requested
> they change some things about the way they work, and they did, and I
> will probably stop looking at that level, and they will move 
> faster.

It is good if this process develops. I was concerned about taking the
mechanisms designed for the harvesters (which have to review lots of small
changes of often unknown quality) and apply them to a larger project.

> That's like saying I don't trust a mailing-list friend because
> I give him precise instructions the first time he drives me home. 
> The issue is not trust, it is information and understanding that
> is not yet shared.

It is trust. Ultimately it is about trust. If you work in a team you trust
your partners to do the right thing. You may have some mechanical means
(tests for example) which ensure that you are doing certain things in a
certain way but ultimately it's about trust. Because if you don't then
you'll spend the rest of the time interfering with the people doing the work
which will drive all of you mad.

> Of course I wouldn't tell the KCP team to go ahead with this project,
> and definitely not commit to spend my time reviewing their work if I
> didn't know very well that I trust them (and that's because 
> I've met and talked technical with each of Alex, Stef, Nathaneal,
> and Roel). A little harder to establish trust and understand
> completely virtually, but not that hard, if both sides try.

Right. And exactly my point ;-)

Cheers,
  - Andreas