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
Cees De Groot writes:
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.
Sounds promising to me, I take it that a major goal is to reduce the load on the harvesting master?
Bryce
On 12/22/05, Bryce Kampjes bryce@kampjes.demon.co.uk wrote:
Sounds promising to me, I take it that a major goal is to reduce the load on the harvesting master?
Well, we sort of decided on that goal of course when started with the Stewarding Teams. My concern after looking what's happening with the Stewarding Teams is that they're too narrow focused, too few people joining, etcetera. It's the same effect you get when you prematurely split up a mailing list in many little list - traffic just dies out. I'd like to specialize them a little bit less, so that each team has a bit more "body".
But yes, the idea is to make harvesting as a centralized task superfluous.
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
Dear Squeakers,
A happy 2006! May the Gods of Smalltalk finally prevail over the dark-roasted side this year ;-).
Recall that I proposed, just before xmas, to move from the current "per-package" team setup (which, in theory, would lead to 10-15 teams maintaining small packages) to a "per logical subpart" team setup, where the subsets would be components like "Core Class Library" (Kernel, Objects, Collections), "I/O" (Files, Network), "UI" (Morphic, MVC), "Development" (Tools and assorted stuff).
It's been a bit silent on the topic - this could indicate a lack of interest, an abundance of people enjoying a holiday, or a silent approval. For the record, Bryce, Brent and Doug reacted in a positive manner, so so far we have 4 in favor and 0 against ;-)
Anyway, if you approve (or not), it'd be helpful to say so even with a little "me too" posting. I think it is a simple and quite logical step, merely fine-tuning what we are already doing, but it could well be that I'm overlooking something here. And with just three people publicly backing the idea, it's a little bit thin ice to start implementing this...
Hi Cees,
Let's hope a bright 2006 for Squeak and Smalltalk in general!
Your idea sounds good and logical. The problem I see is finding someone to lead the efforts in each area. For example, the UI part. I'm the leader of the Morphic Stewards team, and I'm having a hard time just to find enough free time for reviewing the fixes and enhancements that are candidate for publishing. Recently I could not continue my work on splitting and safe removal of packages.
I have a full-time (non Squeak) job, a family (wife and daughter), I'm supervising the works on our new job, and I do some research on signal processing (wavelets and such applied to music, with stuff already published and more to come). Next year I plan to start serious work on developing a pro audio editor using the techniques I developed. I'll do it in Squeak and Morphic.
So, I'm a pretty busy guy. I love Squeak, and believe Morphic was meant to be cleaner and simpler than it got. And I want to use it very seriously in my next project. This is why I want to help here.
But I can't take responsibility for other UI stuff, like MVC, ToolBuilder. And of course Tweak is to be handled by Andreas when released. Actually, I'd like to go in the opposite direction. I'd like to handle Etoys to someone with real interest and knowledge of it.
So, I could agree with your idea if someone proposes for handling all the UI packages. And I'm afraid something similar could happen in the other areas. We are all busy people! Those of us who are lucky enough to work on Squeak have other projects and goals in addition to helping the development of Squeak itself.
I think that in addition to everybody's opinions on this matter, we should also need some candidates proposing themselves for these important positions.
Cheers, Juan Vuletich ----- Original Message ----- From: "Cees De Groot" cdegroot@gmail.com To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Sunday, January 01, 2006 11:31 AM Subject: Re: Steward teams
Dear Squeakers,
A happy 2006! May the Gods of Smalltalk finally prevail over the dark-roasted side this year ;-).
Recall that I proposed, just before xmas, to move from the current "per-package" team setup (which, in theory, would lead to 10-15 teams maintaining small packages) to a "per logical subpart" team setup, where the subsets would be components like "Core Class Library" (Kernel, Objects, Collections), "I/O" (Files, Network), "UI" (Morphic, MVC), "Development" (Tools and assorted stuff).
It's been a bit silent on the topic - this could indicate a lack of interest, an abundance of people enjoying a holiday, or a silent approval. For the record, Bryce, Brent and Doug reacted in a positive manner, so so far we have 4 in favor and 0 against ;-)
Anyway, if you approve (or not), it'd be helpful to say so even with a little "me too" posting. I think it is a simple and quite logical step, merely fine-tuning what we are already doing, but it could well be that I'm overlooking something here. And with just three people publicly backing the idea, it's a little bit thin ice to start implementing this...
On 1/1/06, Juan Vuletich jmvsqueak@uolsinectis.com.ar wrote:
Your idea sounds good and logical. The problem I see is finding someone to lead the efforts in each area. For example, the UI part. I'm the leader of the Morphic Stewards team, and I'm having a hard time just to find enough free time for reviewing the fixes and enhancements that are candidate for publishing.
This may sound like a dumb statement from a management 101 book, but "leading a team" does not equal "doing all the team's work". If you are the only one reviewing fixes and enhancements, something's not ticking in the team...
But I can't take responsibility for other UI stuff, like MVC, ToolBuilder.
ToolBuilder would probably not be a part of the UI team, because it is a separately maintained project. And MVC, well... it is in maintenance mode, quite solid, and "all" you'd need to do as a team leader is to find someone with an interest in MVC, get that person on your team, and delegate the responsibility. In effect a sort of a subteam. The whole idea behind my proposal is to see what subteams do arise, and only if they grow to enough weight (lots of work done, lots of team members, etcetera) to form a separate team.
And of course Tweak is to be handled by Andreas when released. Actually, I'd like to go in the opposite direction. I'd like to handle Etoys to someone with real interest and knowledge of it.
I think the SqueakLand folk should have the responsibility for Etoys. Certainly formally, but quite likely helped by squeak-dev'ers with an interest. Getting SqueakLand into the community development model for Squeak would help getting the two communities to operate more closely.
We are all busy people!
That was actually the main reason I voiced the idea. Because that means we need to be very efficient - if we assume we don't want to have "one man teams", we'd need to have 20-30 people at least, all fragmented over various tiny (thus vulnerable) teams, maintaining all these mailing lists, scattering information, etcetera. Much better to have these 20-30 people, who are all busy, work in teams of 4-6 people (from my experience, that's a reasonably balance, size-wise, between high vulnerability and high bureaucracy).
Yes, the team lead position will become slightly "heavier" (but only slightly so, I think), but overall the community will be able to crank out more work for the same amount of time put in.
On 1/1/06, Cees De Groot cdegroot@gmail.com wrote:
A happy 2006! May the Gods of Smalltalk finally prevail over the dark-roasted side this year ;-).
Recall that I proposed, just before xmas, to move from the current "per-package" team setup (which, in theory, would lead to 10-15 teams maintaining small packages) to a "per logical subpart" team setup, where the subsets would be components like "Core Class Library" (Kernel, Objects, Collections), "I/O" (Files, Network), "UI" (Morphic, MVC), "Development" (Tools and assorted stuff).
[...]
Anyway, if you approve (or not), it'd be helpful to say so even with a little "me too" posting.
Me too, regarding your proposal and best wishes for 2006.
/sge
-- How wonderful it is that nobody need wait a single moment before starting to improve the world. -- Anne Frank Paradise is exactly where you are right now...only much, much better. -- Laurie Anderson
Hi Cees -
I think there are some areas where this can work but you have to be careful to group the right things together. Like, for example, Morphic and MVC are inherently incompatible from my point of view, because they are so different and historically, people who have an interest in one tend to have not too much of an interest in the other. The "core class library" (whatever that may be) might make some more sense here.
OTOH, why force the matter? If you think that Files and Network should be combined into a single team, you can propose that right now. There isn't really a need to make a top-down decision by saying "these are the teams and that's it". Also, I'm not sure I follow your concerns - it seems to me that we really don't have quite enough experience to say what works and what doesn't, so maybe we should give the current setup a bit of time to see if it works out.
So bottom line is that I think I'm neutral on the overall idea but I am strictly against forcing a decision top-down (like "defining" a UI team that consists of Morphic and MVC) since I think that this decision is best left to the people doing the work.
Cheers, - Andreas
Cees De Groot wrote:
Dear Squeakers,
A happy 2006! May the Gods of Smalltalk finally prevail over the dark-roasted side this year ;-).
Recall that I proposed, just before xmas, to move from the current "per-package" team setup (which, in theory, would lead to 10-15 teams maintaining small packages) to a "per logical subpart" team setup, where the subsets would be components like "Core Class Library" (Kernel, Objects, Collections), "I/O" (Files, Network), "UI" (Morphic, MVC), "Development" (Tools and assorted stuff).
It's been a bit silent on the topic - this could indicate a lack of interest, an abundance of people enjoying a holiday, or a silent approval. For the record, Bryce, Brent and Doug reacted in a positive manner, so so far we have 4 in favor and 0 against ;-)
Anyway, if you approve (or not), it'd be helpful to say so even with a little "me too" posting. I think it is a simple and quite logical step, merely fine-tuning what we are already doing, but it could well be that I'm overlooking something here. And with just three people publicly backing the idea, it's a little bit thin ice to start implementing this...
Hi people!
Andreas Raab andreas.raab@gmx.de wrote:
Hi Cees -
I think there are some areas where this can work but you have to be careful to group the right things together. Like, for example, Morphic and MVC are inherently incompatible from my point of view, because they are so different and historically, people who have an interest in one tend to have not too much of an interest in the other. The "core class library" (whatever that may be) might make some more sense here.
OTOH, why force the matter? If you think that Files and Network should be combined into a single team, you can propose that right now. There
And being the Network team leader I would not object to such a merge. :) The areas do intersect quite a bit and are on the same conceptual level (pro merge) and a merged team would still be specific enough to hopefully work efficiently. Any arguments against such a merge?
isn't really a need to make a top-down decision by saying "these are the teams and that's it". Also, I'm not sure I follow your concerns - it
I agree - no real need for a top-down decision. Hopefully it will sort itself out and personally I have from the start argued for larger packages that break themselves down when it seems suitable.
But I agree with Cees - we should not create "too small" teams just because there happen to be some kind of PI structure in the image fitting it. In other words - there is AFAIK no "preferred size" when it comes to forming teams - if a larger team seems reasonable, go for that.
seems to me that we really don't have quite enough experience to say what works and what doesn't, so maybe we should give the current setup a bit of time to see if it works out.
Agree with that too. :)
So bottom line is that I think I'm neutral on the overall idea but I am strictly against forcing a decision top-down (like "defining" a UI team that consists of Morphic and MVC) since I think that this decision is best left to the people doing the work.
Cheers,
- Andreas
Agree.
So I agree with you both :). Let's form teams, large or small - lump them together or split them apart - as we see fit.
regards, Göran
On 1/2/06, Andreas Raab andreas.raab@gmx.de wrote:
OTOH, why force the matter? If you think that Files and Network should be combined into a single team, you can propose that right now. There isn't really a need to make a top-down decision by saying "these are the teams and that's it".
Well, the idea is to move towards a model where all patches/bugreports etcetera in Mantis land with anyone team, the teams modify the code, and the 'release team' (like v3.9a) only integrates. At the moment, most of the image is not carved out so the 3.9a team still bears the burden of going through Mantis, doing bugfixing work, etcetera - detracting from integration, QA, and stuff I feel (and I hope others) that a release team should be concentrating on.
And no, there's no top-down decision making here. Just a community "decision" that this idea makes sense. So that we can actively hunt for people who want to maintain these larger chunks of code instead of having a very long list of PI's up representing possible teams.
As you say, no-one can force such a decision so if the current Morphic team - as already has been indicated - wants to keep churning on Morphic, who am I to override them? There are arguments before and against putting them under one team, and in the end, all we can do is present our arguments and let the team leader decide.
Hi all
I agree with Andreas and Cees. I favor any initiative that makes the system moving faster.
Stef
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Brent Vukmer -
Bryce Kampjes -
Cees De Groot -
Doug Way -
goran＠krampe.se -
Juan Vuletich -
Steven Elkins -
stéphane ducasse