Hi people!

Yeah, I know - god damn all these emails... But this one is *important*.
:) And I did try to trim it down, but I know, I suck at short emails. ;)

This is a proposal on how we organize ourselves in Teams around
different tasks. If you read Report 1, this was mentioned - but not
explained further, because it was only sketchy at the time.

	** This is an important part of how we want to work, please give us
feedback **

We (the castaways, eventually to be renamed to something better we hope)
are primarily focusing on getting this community working better. This
means getting processes defined and working - not playing dictators and
taking lots of cool technical decisions in a closed room. *Really*. :)

We are not fooling ourselves thinking that *we* four can invent the
future Squeak. We can't. We will of course eat our own dog food and get
busy in the various tasks (we are still bootstrapping here, emailing
about "processes" isn't all we will do) but that is just like it has
always been.

Now, one of these "processes" we keep yapping about is how to partition
our efforts in this community. If we think back on the history of
squeak-dev we have been *lousy* at working in teams. SqC didn't really
do anything in that direction and the Guides - we didn't either - we
sucked just as much as SqC. :) But we think this is a *key* issue.


Teams
-------
When there is a need perceived in this community, call it a project or
task or whatever, we will try hard to detect it. If you think there is a
need to be adressed - say so. What we will try to do then is to find an
individual Squeaker to grab that issue by the... mouse ears, and form a
Team around it. I just use capital T to denote that we do have some
(few) rules about such a Team:

1. A Team is started when a Team leader is assigned. This is today done
by us, but later on the model will of course be based on whatever comes
out of the SqF work. We also assign one of us to track that Team and to
keep in touch with the Team leader. From then on the Team leader takes
over.

2. The Team should work openly. No private areas or private mailinglists
etc. Setting up an ml or a Swiki is of course fine, but it should be
readable by us all. We don't want to endorse "secret" work.

3. Anyone can join a team, but the team leader *is* King. I mean, if
some wacho joins and starts shouting "Java! Java!" then the leader has
our support in kicking the wacho. :)

4. After the Team is started we would like to get *some* plan from the
team leader. It doesn't have to be complicated at all, just some
statement on the intentions on how to proceed.

So obviously the Team leader has more or less total power, which also
means responsibility. The Team may fail to deliver of course, no big
deal, but managing the Team should be cared for by the team leader
regardless of such a failure.

Now... what are the effects we hope to get out of this model?

- Since we keep track of Teams and Team leaders and since we track their
status, just that simple thing will make it much easier for all of us
knowing "What is going on?". This issue is one of our burning ones, btw.
It means you can always take a look at the Team table - and voila, there
you see whom to contact etc. For example, currently you see that Cees de
Groot is team leader on MinimalMorphic - so if you like to help with
that (stripping etc) - talk to Cees.

- Since a team leader is sticking out his/her head and actually takes
responsibility *and* is being delegated full power, we think the
incentives for actually getting results done is much higher than before.
And the Team can rest safe that their work isn't going to be forgotten
and generally thrown in the garbage bin.

- The noise on squeak-dev should hopefully go down a bit. This is also
one of the burning issues.

- Also it will be quite clear that we (castaways) are actually much more
in the coordination business than in the Dictator business or in the
SuperCoder business.

Of course, we are not saying forming a Team is the only way to work in
the squeak-dev community, but it would have a few advantages compared to
"just doing it":

- The Team gets one of us tracking it and helping out with coordination
with the other Teams and release planning. Hopefully a valuable service.

- The Team gets our feedback, which of course may be crap but we will
give it. :)

- When results are about to be delivered our group is there to help in
getting it received and properly dealt with. It is our responsibility to
make sure a Team doesn't work a lot on something that then doesn't get a
proper reception.

- And of course, a Team has our support, since we are doing the above.
Such endorsement may be worth less to some, but it is there anyway.


Now people, how does this model sound?

We currently have 4 running Teams:

	- File area, with Bruce O'Neel as team leader.
	- Box1 administration, Cees de Groot as team leader. (not much work
here for the leader)
	- New web site, with Stephane Ducasse as team leader.
	- MinimalMorphic, with Cees de Groot as team leader.

(the other Teams listed don't have an assigned leader yet and are only
on the sketch board so far)

And... if say Ken Causey would like to be team leader for Box1, then I
think Cees might just jump with joy and hand it over. :)

Tomorrow we will post regarding forming two quite important Teams.
Now, please give us feedback on this stuff. If no feedback is given we
will simply move forward with this as described.

regards, Göran