David Grove writes:
> If I understand correctly, large teams would have a small team of
> "control" (bad word, but I don't know how else to put it) with a
> team manager for that team, and small teams (like the ones with two
> or three members, that have been pointed out) would be their own
> "control" team, and unanymity of teams would be required for
> release, is that a good summation?
I think so, although I'd have written it better.
The ongoing maintenance of Perl will involve work done by teams of
people. Each team focusses on an area: compiler, regex,
documentation, etc. The teams will obviously work together at time.
Each team has three roles identified: the person who checks in
patches, the person who represents user interest in that area, and the
person who QAs that area. There may be others, members of the public,
but these three are the ones who must be satisfied with a release
before it can go out. There is no team leader, merely the union of
those three people. The release manager is there to help each team
work with its team members, and to help teams work together.
The system is self-balancing. The release manager cannot override a
team that will not approve a release. If teams want to kick out the
release manager, they can get together and do so. The release manager
should be involved in intra-team disputes to ensure that booting a
team member out is an action of last resort and not merely a way to
force a release through over valid objections.
> Anyway, it's definitely moving in a good direction, and shows
> potential to solve a majority of problems. Yes, this is a good
> direction.
What else is there to say? I want to get this topic dealt with so
we can return to the more pressing tasks:
- how will we evolve and record design decisions (the RFC or
RFC-replacement)
- by which people and in what groups will design take place?
I tend to lose patience with any thread that goes on for longer than
three days, so we're reaching the end of my ability to focus here :-)
Nat
