Initial Structure

[email protected]
  This list is for discussion of internals design, architecture
  changes, embedding, extending, and so on.

[email protected]
  This is for discussing user-visible changes to the language.

[email protected]
  This gets copies of all the perl6-* traffic.  Intent: if you reply to
  a message you got via this list, your reply goes to the original list.

[email protected]
  This is a moderated list, for news of new lists, RFCs, working
  groups, and so on.


The internals and language lists need chairs.  The goal is to develop
RFC documents about proposed changes to Perl.  The chairs can spin off
sub-groups to tackle particular issues, each with goals, a chair, and
so on.  The chair's responsibility includes weekly summaries a-la
mjd's p6p reduxes, but the chair may delegate to someone else.  The
summaries are sent to the parent list.  Summaries of language and
internals are sent to the announce list.

The mailing list chairs have access to a web page on perl.org that
makes it easy to create or destroy mailing lists.  Once a mailing list
is destroyed, its archives are put onto the webiste.

We still need an RFC format.  Dan was going to come up with a draft
format.  If he wants to punt, I'll do it tonight.  Right now I'm
picturing:
 - Abstract
 - Description of the change
 - List of possible implementations (doesn't have to be at the bit
   level unless you're talking a bit-level change) that were discussed,
   with quick summary of pros and cons.
 - Suggested choice of implementation.

I suggest that the working group chairs come up with an initially
brain-stormed list of topics and then find editors for the RFCs.
The RFC writing process is just to ensure every change is written up
and researched.  I don't expect it to be painful.  Not every RFC will
need its own list, only particularly thorny issues.  It's up to the
editors and chairs to decide when new lists are needed.

Comments?  I'd like to have Ask set this up Thursday.

Nat