Nathan Torkington wrote:

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

> 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).

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

[rest of excellent ideas cropped]

Nice. I like it alot. The one thing I don't like is "comment in
private", but see below.

My main concern at this point is *how* these teams are assembled. Here's
my shot at a relaxed yet fair process, let me know what you think. The
specification seems long (just so I can be clear), but it's actually
pretty simple.

1. With either development or maintenance, at some point it's generally
decided that something should warrant a team. For example, perhaps Async
I/O, or Unicode, or whatever. Somebody volunteers to be "team lead", but
not that they have any more authority, just that they guide stuff
similar to sublist chairs. The team lead should also be responsible for
making sure their team is properly in synch with other teams.

2. The team lead puts together a short synopsis of what's required for
the team, what the private sublist is going to be, and how many people
are needed. This synopsis is posted on

3. Prospective members then email the team lead, asking to be on the
team. The team lead is responsible for asking them "What are your
qualifications?" or "Why do you want to do this?" or whatever. Through
this process, the team lead selects their team and sends the list to Ask
(or whoever's in charge of sublists). Those members are added to the
sublist, and the team description on is marked as "closed".

4. The team uses the private sublist to conduct their business. Others
can read the archives, and observe. To post concerns, anyone should
still be able to email the private sublist, on a moderated basis (like
perl6-announce). That is, emails to the private sublist from those not
on the list should have to be approved by the team lead. That way,
reasonable concerns can still be raised publicly (and archived
correctly), and useless/out-of-date ones can be denied or answered
privately. It also prevents people from posting to -internals or -meta
with "Those -internals-io people have it all wrong, blah blah blah".

So, for example, if -internals decided that an Async I/O group was
needed, and Uri volunteered to lead it, it might look something like

   Name: Asynchronous I/O
   Lead: Uri Guttman <[EMAIL PROTECTED]>
   Needs: 5-10 people
   Members: (open)
      This team will be responsible for the design and implementation
   of fundamental asynchronous I/O for Perl 6. Those interested should
   be experienced with low-level I/O programming, such as UNIX device
   drivers or STREAMS. We will be designing I/O API's, prototyping,
   and finally writing production code for inclusion in Perl 6.

People would email Uri for membership, etc, etc per the above steps. On
selection of the team, the "Members" section would include the names of
those involved, and the "Needs" section would be marked as something
like "0 people (closed)". Then the team uses the private sublist to
design, code, etc, etc.



Reply via email to