The PDD process revisited....

Here's my attempt to summarize the recent discussions about the PDD and RFC 
processes, answer any questions, and throw out some ideas.  I have 
attempted to attribute the various bits of the discussions.  It you have 
been omitted, it was not intentional.  If I have misrepresented you, please 
correct.  Recommendations follow (at - Recommendations).

- Submittal Process

The official PDD announcement channel is the perl6-announce-pdd mailing 
list at perl.org. (Ask)

The official PDD submission channel is perl6-pdd@perl.org; however, until 
further notice, PDD submitters may post to the appropriate group and cc: 
perl6-pdd.  (This will not be in the PDD.) (Ask)

- Writing a Standards-track Proposal

Currently, there is no restriction on the Whos, Whats, Whens, and Whys of 
PDD Proposal creation. (Adam)

The original intention was that the standard mailing list mechanism would 
feed the PDD Proposal process, either at the instigation of the WG Chair, 
or through the initiative of a participant.  This has a couple of problems:

    Several competing PDDs may be submitted. (Adam)

    PDDs may need to precede discussion. (Adam again)

    The lack of enforcement may lead to PDDs that are "out of left field" 
(still Adam) and may not reflect the Perl community's vision. (Simon, sort 
of)

Potential solutions:

    A WG Chair must authorize (or sponsor) a PDD before its Proposal.  This 
could either be a simple CFP, or an email asking for permission to write 
one.  (For instance, PDD 0 itself was written only after I emailed Dan and 
asked if I should and could.) (Bryan)

    Let the community continue to be self-governing.  PDDs that shouldn't 
be will be corrected.  (Simon)

    PDDs should reference/include/summarize X percentage of the discussions 
to date. (Adam)

- Continuation of the RFC Process

With the formalization of the PDD process, the only vehicle that remains 
for the submission of All Things Kooky is the mailing list.  Unfortunately, 
this is exactly what the PDD process was created to prevent - the flooding 
of the various working groups with traffic that has no business being there.

Potential solutions:

    Continue with the RFC process (Edward, Dan), although not under that 
name (Nathan).  Edward and Peter gave ideas as to how this could work.
Adam pointed out that the RFC process from this summer was "formally and 
intentionally closed".  And a while ago, Nathan alluded to the one-timeness 
of the RFC period.  (IIRC, it wasn't the idea of one, but the particular 
form it took.  More or less like, it was a prototype.  If we want a working 
model, let's learn from lessons learned.  Is this more or less correct?)

    Revamp and/or expand the PDD process to create a Random Submission 
process. (Adam, Nathan)

- Multiple Documents and Names

The original intent of PDD 0 was to provide a generic vehicle for 
documenting All Things Perl.  Despite any implications of the name "Perl 
Design Document", segregation on Track-type and Class should provide enough 
arenas to logically group PDDs.

Nathan provided possible names for a seperate vehicle model.  (Although I 
will point out that both the internal and language documents were both 
Design Documents.)

- Other problems

Inability to reference multiple PDD Proposals for a single topic. (David)

No versioning capability for the Standards themselves.  (In other words, a 
PDD may have been declared a Standard at document version 5, and again 
(after changes) at document version 11.  There is currently no way of 
easily referencing which Standard.)

Insufficient explanation of Informational and Experimental PDDs.

An inherent inability to handle negative documentation.  (IOW, we're not 
doing this, but not because we're doing something else.  We're just not.)

In the case of multiple Proposals, there is a implied "rejected" 
repository.  Unfortunately, this is Yet Another Arena that would need to be 
searched.

- Recommendations

All PDD proposals must be instigated/approved by a WG chair, PM, PK, etc.
Submissions do not need to be made through the WG chair, nor does the Perl 
Librarian need to do any tracking for "approved" PDDs.  Anyone submitting 
unauthorized PDDs to the Librarian will be subjective to repeated 
hand-smackings.  By a nun, for a second offense.  She gets a yardstick for 
further offenses.  (When asking for approval, it may be good to give an 
idea of what you are going to write about.)

However, anyone can write up a skeleton PDD proposal and submit it to the 
appropriate list.  (To alleviate confusion, omit the VERSION section in its 
entirity.)  The WG chair must still give approval before its submission as 
a formal PDD proposal.  Misuse will result in Stoogian eye-pokings.

The PDD wil remain a vehicle for documentation, and not for brainstorming, 
bitching, moaning, etc.  The RFC process should continue, in a form (and 
forum) to be decided seperate from this discussion.  Any subsequent 
references to the RFC process imply the result of those decisions.

The PDD should continue to be a single document, and adapt to parallel 
uses, vice creating an entirely new (parallel) mechanism.  Possible 
exception: I am still mulling over how to handle explicit change requests, 
which may warrant a vehicle of their own.  We may want to consider a name 
change for the PDD, however.

There shouldn't be a formal mechanism for creating distinguishing names for 
competing proposals.  Firstly, there shouldn't be very many cases where the 
situation is so open-ended that there will be more than a couple different 
ways to handle it.  Secondly, the Perl community is rather clever, so even 
if Simon submits three or four competing Proposals for the same PDD, 
someone will come up with a way to distinguish them.  (I suggest using the 
lyrics of "Hickey, Hockey, Holey" as keywords :-)

Standards should be versioned according to the first version of Perl that 
they represent.   Standards -> document version is already mapped in the 
HISTORY section of the VERSION information.  However, there isn't any 
mapping from standards to the perl that the standards are for.  This 
versioning scheme provides that mapping.  Incremental versions would 
require a seperate mapping mechanism.  (IOW, all the PDDs being generted 
now are for Standard versions 6.0.)  This more or less continues the 
informal versioning of various Perl subsystems, like "the regex engine is 
Perl 5.6 compatable".

The descriptions of Informational and Experimental PDDs will be beefed up; 
however, the following restrictions should be levied: 

Informational PDDs must be objective, and can be {shudder} "corrected" by 
the WG chair, et al.  (Yes, I'm well aware of Thomas Jefferson's 
interpretation of the First Amendment and the consequences thereof.  Let's 
just say, the goal is not censorship, but objectivity, which can itself be 
subjective, unfortunately.  The former is the prevention of reporting a 
truth, the latter the prevention of reporting a truth as THE truth.)  To 
give a Perl example, you can't say that there is a conspiracy between 
Microsoft and ActiveState to destroy/control Perl, but you can't omit that 
there is a vocal percentage of the community that says there is.  Yes, this 
may reek of PC.  No, every "outlying data point" need not be considered.  
The WG chair makes a determination of what is outlying and what isn't.
Someone is going to be left out, but unfortunately, this is the only way I 
can think of to ensure that an Informational PDD remains a voice of a 
community (that may potentially disagree), without becoming a voice of an 
individual.  If this pisses you off, I'll be glad to listen to your counter 
arguments on one condition: you tell me whether or not this situation will 
arise.

Experimental PDDs must include or reference an actual implementation of the 
experimental behavior, along with a reference to the baseline it is applied 
against.  Expermental PDDs are *not* for hand-waving what-ifs.

Informational PDDs can be written as "negative" documentation.  (We don't 
do this.)  However, the aforementioned RFC process should handle the bulk 
of this, I think.

Rejected PDD Proposals should be automatically submitted as an RFC, 
indicating that it was a candidate proposal for PDD #, but was rejected.
This will provide a single repository for unimplemented ideas.  

__END__

I apologize if I'm being rather anal about this.  I'm giving a solid PDD 
foundation a 50/50 chance of actually working and lasting a single revision 
of Perl 6.  Anything shakier, and it may not be worth the time to even 
bother.

-- 
Bryan C. Warnock
bwarnock@capita.com

• The PDD process revisited.... by Bryan C . Warnock