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 [EMAIL PROTECTED]; 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
[EMAIL PROTECTED]
