goran.krampe at bluefish.se wrote:

>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?
>  
>
It sounds ok, so far. Squeak work can be naturally partitioned to 
facilitate teams -- and we have all been trained to work in teams... 
seems inevitable and fun ;-)

You mentioned
"When results are about to be delivered our group is there to help in 
getting it received and properly dealt with."
But, there is no explanation of how the output of teams is integrated 
into the image or packages (or whatever). And who is responsible for 
this work. Is it your team? Or is this another team (the base image 
team, or the packagers, or harvesters, or ?)

Is it up to the team and team leader on how they plan, code and deliver? 
Who is responsible for what the team actually produces? That is, who 
decides that functionality X is needed not functionality Y? (perhaps 
it's a requirement that plans be brought to the squeak-dev list for all 
to comment?)

Who has the authority to kick out the team leader?

 Also, how do teams cooperate? Perhaps the conduit is the team leaders?

brad