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