Andreas Raab <andreas.raab at gmx.de> wrote:
> 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? 
...
> 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.

Hmm, I think you're right, maybe this discussion isn't about procedures
or even specific goals that are shared or not, but about the really
basic picture of What Squeak Is for different people. Maybe this idea is
so basic to most participants that it's hard to imagine someone else
might not see it the same way...

> > 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
> ;-)
:-)

Actually, I think of Squeak as the kind of platform that a Computer is
in my eye supposed to be(*), or the way it is thought of by someone
unafraid of computers. That is, it's a language and class library and
environment that allows you to express a lot of computational ideas
efficiently. I consider the proliferation of innovations that happen in
Smalltalks to be a result of it efficiency as such a platform. To me
Squeak is no more (or less) a platform "for media" than it is "for
computation neuroscience", which is what I'm currently dabbling in, or
webservices.

An important aspect of being a good platform for expressing
computational ideas efficiently, is that the system must be easy to
learn at the levels in which it is being used. Within EToys, that means
having a little more complexity that hide Squeak itself. But for all
other levels, that means Squeak itself needs to have flexible, simple
structure. 1000 class all interdependent don't fulfill this goal very
well. Being able to identify (and load) a subset that interests one, and
study just that, helps understand "the system".

So I think that the download page should include an image for "The
Squeak media platform", but I also think it should have an image for
"Learnable Squeak", which includes only that which helps to understand
the system itself. I don't know if that means having only a Browser, or
if it should be as bare as a Commodore64, but it should definitely not
have sounds, movies...

> [... 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...

This feels abstract to me. Who wants what guidance that's missing?

> > 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?

I feel this question is leading us away from the topic. In short, I give
priority to what will 
- clean up Squeak (KCP, MCP, Removals) or
- get it cleaned faster (SM 1.1, changes to the harvesting process) or 
- improves stuff that is required for everything else (text editing
(including scripts), sockets, compiler, basic interaction stuff in
morphic)

But that which is not my priority, and I might forget, you can still
push for. What's the big deal? 

> > 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.
This is fascinating. Ok, I asked. We talked about it, even had some
agreements. And now what's stopping you from pushing stuff to happen?
for example, compile a list of issues in Yoshiki's code, suggest a
subset of the code that doesnt have issues, and post it as an ENH.
Whatever. I'm not The Boss, I'm a Guide. I try to surface the important
issues. If someone rises to the occaison and answers the questions, and
makes the thing reality, wonderful. If not, too bad.

(Using the personal here, other Guides might feel differently) How is my
memory special? people, I don't know how to say this. My memory stinks.
Don't wait for the call, you'll just suffer. Instead of suffering, enjoy
it - tell me I agreed to this last time, I'm usually too lazy to check
the archives ;-) but for gods sake, don't expect me to remember your
issue. Might as well expect me to float. Expect from me the little that
I can provide.

To try and summerize this part of the thread - anyone that wants to can
drive stuff to happen faster in Squeak. And in the general case, this
will not happen automatically.

> 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.
Even in those mechanisms I expect things will get smoother as they're
used.

> > 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.
Call it trust. No, I don't trust practically anyone to know what
constitutes documentation I understand until we've done a little work
together. Working with a detailed version of the process for a short
period of time builds that trust.

> 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.
If I can't get to trust someone in a short period of time, I won't
interfere, I will let them know and stop reading their code. Life is too
short for both sides. I think sometimes face to face communications will
help, or maybe another Harvester will understand that person better.

> > 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 ;-)
Great. So you'll think a little about how we can start merging pieces of
Open Croquet, and where's a good place to start? :-)

Daniel