Here are some guidelines for the design process for internals-level docs.
1) The damn things will be called PDD, or Perl Design Documents. Calling
them RFCs was getting confusing for those of us dealing with IETF RFCs,
especially as we're edging in towards the active RFC range.
2) We start counting from 2. (RFCs 0 and 1 are reserved, in case anyone
beats me to them)
3) The format of the previous RFCs will be followed. The implementation
section is optional, though strongly encouraged where appropriate. The
status field is mandatory--PDDs submitted without one get a status of
4) The PDDs are real documentation. When one goes to status:Standard, it
*will* describe reality. If, when reality materializes, it doesn't then it
needs to be updated. Someone should, for example, be able to take the PDD
on vtables and write their own perl datatype without needing to refer to
5) The stauses for PDDs are:
proposed: Someone's putting forth a concrete proposal
developing: The PDD is in active development and considered a real part of
standard: The PDD's done. (Well, for now at least)
superceded: The PDD's been replaced by another.
informational: The PDD is merely informational, and not a standard
experimental: The PDD describes an experimental thing, and isn't a standard.
6) Only a WG chair, pumpking, or one of the principals (i.e. Me, Nat, or
Larry, or our replacements) can mark a PDD as developing, standard, or
7) These are *not* brainstorming documents! These are solid, concrete
proposals for either the design or implementation of perl 6. If you have a
brainstorm but don't currently have the skillset (or requisite brain
damage... :) to make a concrete proposal, get in touch with either the
correct WG chair or Nat or me, and we'll do our best to hook you up with
someone in a position to make your ideas concrete.
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk