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]