Mailing lists and RFCs

Ask, please create these lists:

[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.
  Internals: Dan Sugalski <[email protected]>
  Language: ??? (did someone put their name forward?)

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.  New lists do not inherit their
parent's subscription list.  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.  This to be
written by MjD with Ask.

The RFC format is plain text, slightly structured.  I've enclosed
a sample at the end of this message.  The major components are:
 - Title
 - Metadata (Maintainer, Date, Version, Mailing List, Number)
 - 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.

The RFCs are submitted by the maintainer to the librarian, who assigns
a number if they don't already have one (updates to existing RFCs
don't need new numbers, but the librarian can be asked by the
maintainer or parent group chair to retire existing RFCs if they're
dead) and sends them on to the mailing list.  The Reply-To: of the
posted RFCs are set to go back to the mailing list on which they're
being discussed.

RFCs may evolve over time, and initial postings are expected to be
incomplete.  Most RFCs in the description of the change request should
mention possible effects on embedding, threading, reentrancy,
security, porting, and testing.

I'm not sure if this sample RFC is suitable for the web site.  I'd
like a volunteer to make a better sample RFC to put on the web
site to show people how it is to be done.

I'm sure this isn't the best RFC format.  Until we start writing RFCs
and seeing how they're developed and expressed, we won't know a better
format.  Hopefully this is sufficiently easy to write that we'll start
using the system and sufficiently easy to parse that we can automate
most of the work in converting them to any new format later on.

Nat


Sample RFC: This Is The Title

Maintainer: Nathan Torkington <[email protected]>
Date: 1 April 2000
Version: 1
Mailing List: perl6-internals
Number: 1

Abstract
--------

Perl6 should have no dollar signs.

Description
-----------

The dollar signs make Perl hard to read, therefore the language should
not have them.  All variables would be scalars, and the dereference
syntax used to access complex data structures.

This can go on and on for section after section.

Implementation
--------------

This could be done two ways: with a rewrite of the parser or with
a modification to `use strict'.  `strict' is probably best.

Parser
------

Modifying the parser would involve bad juju.

strict.pm
---------

This might be retrofittable to perl5.