I think we're talking about two different periods of development here.

The immediate question facing us is how to structure software design.
This is different from the ongoing maintenance of Perl.

We want and need a small group to design perl6 correctly.  I can't see
this working any other way.  Software design is a completely different
process from maintenance, and it's unrealistic to expect the
maintenance model (big open mailing lists, everyone says what they
want) to work for an intently cerebral activity.

Design I'm seeing as in two parts: architecture (what are the major
components we need?) and detailed design (where each component has
an API designed and the interactions between components resolved).
The architecture will be partially decided by Larry, and seems best
done by a few experienced with such things.  Detailed design seems
appropriate for groups of 5-10 people in each area.  In both cases,
public viewing of the proceedings is mandatory (you can read their
messages and see their thoughts and comment in private).

Implementation is different from design, and different again from
maintenance.  If we do the design, test cases, and stubbing well
enough, we could have a cast of thousands doing the implementation.

I honestly don't see us arguing over design.  Or even over
implementation.  The big meat of this discussion so far seems to have
been how to prevent the ongoing maintenance of Perl from being
coopted.

I'm thinking about a team structure for ongoing maintenance.  Each
area (docs, stdlib, interpreter, compiler) has its own team.  A team
is only a few people: the person responsible for submitting patches,
someone responsible for keeping on top of user demands, and someone
from QA.  In some cases these roles might be shared, and there's no
law that says the same QA person couldn't be on several teams.  The
only law I'd want is that no team could be made up of people from
the same company.

In addition to these people is a release manager, coordinating with
everyone to set realistic deadlines and ensure everyone's talking with
everyone else.  No release goes out the door until all the teams agree
that they have a Good Enough product.  This way neither ActiveState,
Microsoft, nor the Trilateral Commission can dictate an unrealistic
release date.  And this goes both ways: if there is a dodgy release,
the blame can't be pointed at just one company.  At a team perhaps,
but there can be no accusations of coercion and manipulation.

I don't see voting having a role in any of this, except as a crude
opinion poll for the internal equivalent of Marketing.  Voting doesn't
work in the real world, and in an online world where you can't even
make someone respond to your email, I see it being even less
effective.

How's this sound?

Nat

Reply via email to