Andreas Raab <andreas.raab at gmx.de> wrote:
> However, I have the feeling that
> people do expect two things from the guides: a) a bit of project management
> and b) strategic guidance. The first point really means that if someone goes
> through all the effort which is required to even get close to inclusion it
> is (in my understanding) not acceptable if that's simply "not remembered".
> It can't be too hard to have some TODO list on a Swiki which gets checked
> every other month or so, can it?

About keeping a todo list:
You're right, it probably isn't very hard. And I know I at least have a
terrible memory, and could use some help with this. Can anybody help
with this?

> The strategic guidance thing is more complex but it's the issue I am even
> more concerned about. As of today I don't see the guides (as a group) have a
> vision in which to steer Squeak. This means that for anyone who wants to do
> something it isn't clear at all if that's somewhere on the "critical path"
> to where Squeak is headed. Thus far, all of the activities coming from the
> guides seem to be purely infrastructural but infrastructure needs to serve
> some purpose. And I don't see any visible direction in which this purpose
> might lie. 
What is the "direction" of Linux? is it to be a wonderful multimedia
application? is it to be the fastest web server in the world?

Linux is a platform. When a bunch of linux people heard of a (skewed)
benchmark in which Windows actually got better performance, and it
mattered to them, they rewrote the network layers for better SMP
performance and pushed for it's acceptance. If someone pushes for some
change to hardware accelaration of media operation, and brings code,
that will be considered. Who makes the strategic direction for Linux? 

Squeak is a platform too. It can be anything you guys want it to be. If
the core remains maintainable, and easy to build on.

> Which, by the end of the day, leads to the situation that when
> people want to touch anything, they first query about it on the list which
> leads to endless discussions, then they do something and then it may well
> get forgotten. Not good.
You mean, excluding the whole world of things that can be done outside
the image and will now be available from SM.
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.
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. It
doesn't have to be forgotten, but I see no reason why it's expected that
it be remembered by the the Guides.

The only place where I see that remembering other peoples stuff is
specifically for harvesting stuff. However, this is now a more open
process than it ever was. There is no mystery ("has SqC looked at my
patches to the DamageRecorder yet?"). Either it has reviews, but not
definitive comments, and you're being ignored (it's not personal :-),
and should sell it better, or it's [approved] and it will be in in a
matter of time.

> Finally (because I'm just at some larger issues) consider dropping the
> "micro management" approach for larger projects. This just won't work. 
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. As
the project progresses, pretty quickly I will look only at the design
level question, as you suggest. I don't know a better way to establish
understanding.

> You
> can't spend the time to review each of the CS' produced by teams (such as in
> KCP or MCP). You need to have a basic level of trust. For example, if the
> KCP team says "we're going to move all the navigation aspects into
> SystemNavigator" or somesuch then it's appropriate to discuss the top-level
> design decision but you can't review each individual CS. It makes no sense.
> It only eats up time 
No, I think some reviews of the code itself are essential for clearing
up misunderstandings. Without a shared history, words are too imprecise.

> and the impression you leave is that you don't even
> trust the team in question to handle something as simple as moving a method
> from A to B. If that were really the case, then these teams shouldn't do the
> work to begin with.
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.
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.

> > BTW, I think it's important to achieve this again that stuff like
> > OpenCroquet and it's parts get fed back into the core (some into the
> > image, some into packages). I'd like all of us to find a way 
> > for that to happen.
> 
> Sigh. Do you really expect us to justify each line of code we're writing for
> Croquet? You gotta be kidding me. Either there's some level of trust in the
> work we do or we'll all going to get crazy before long.
Of course not. I expect and hope that we'll work a little at first
hashing trivial details (no, I meant left *at the stop light*!) until we
get a good feel for where the other is going, and then just run with it,
discussing only the major issues.

> Cheers,
>   - Andreas