Sounds like exactly the right approach.  I'd advocate going ahead with
this, at least in terms of team organization and team mailing lists.

Then, if some stewarding teams are large enough to split apart further,
they can split apart.  (About the only example I can think of that might
be ready to split off would be MVC vs Morphic.  But yes, just start with
one larger UI team and then let it split apart when it is ready.)

Once these teams & mailing lists are organized, come back here with a
list of who's on what team, and beg for more volunteers. :-)

- Doug


On Thu, 22 Dec 2005 02:34:30 +0100, "Cees De Groot" <cdegroot at gmail.com>
said:
> This is just a quick ramble before I go to sleep - interpret it as such
> :)
> 
> I've been a bit worried about the lack of manpower in the Stewards
> teams. Not about the current absolute numbers, but the fact that with
> the current granularity, we'll need a lot more teams and thus people
> and I'm not sure where we are going to get them from.
> 
> At the same time, I think we all agree that we should move away from
> the monolithic development mode where one team maintains everything.
> 
> Therefore, I would like you to think about an intermediate way: cut
> the image in rough chunks, maybe four our five, and assign these to
> teams. "Core Class Library" (Kernel, Objects, Collections), "I/O"
> (Files, Network), "UI" (Morphic, MVC), "Development" (Tools and
> assorted stuff) is more or less along the lines I'm thinking of
> (again, I'm just throwing an idea at the list so I haven't checked
> whether this way of cutting covers everthing).
> 
> Four teams are easier to staff than the 10-15 we'd need if we keep the
> package-level granularity. And when the teams grow big, they can
> always divide work internally, and maybe later on split up when it
> makes sense.
> 
> Anyway, sounds truer to "divide and conquer" than what we're currently
> doing (which a pessimist might interpret as "chop and destroy" ;-)).
> 
> G'night,
> 
> Cees
>