Re: State of PDD 0
Adam Turoff [EMAIL PROTECTED] wrote: On Wed, Feb 21, 2001 at 07:44:51PM +, David Mitchell wrote: Also, if we go down the 'have a competition to see who can write the best PDD on subject X' path, can we replace the 'TBD' in unnumbered PDDs with a short string chosen by the author? This allows us to (hopefully) unqiuely refer to a document during disussions, but when a final winner is chosen and given a number, the offical library can still pretend the losers never existed, unless people look in the 'losers' section. EG PDD-dapm-GC rather than PDD-TDB for my attempt at garbage collection or whatever. There are advantages with using simple enumeration for RFCs/PDDs. (I'll beat that dead horse only upon request.) The disadvantage of switching to a more descriptive naming scheme is that any identification attached to a PDD upon receipt must be final; a PDD cannot be renumbered/renamed once it has been accepted into the archives. To do so would make it more difficult to search the archives for discussion about an idea -- searching on PDD-std-vtbl won't find the threads that lead to that standard, when it was called PDD-sugalski-vtbl. Perhaps a more descriptive prefix/suffix notation on PDDs would improve upon the anonymous nature of RFCs/PDDs, so long as a core name is assigned to a document never changes. I think you misunderstood what I was suggesting. Take GC as an example. At the end of the PDD process, I want to see in the library a single doc called "PDD-3: Garbage collection". What I was thinking was that if the process leading to that document involves several competing designs being hammered out on the perl6-internals list, then each competitor writes an 'unoffical' PDD which is just a form of text that gets bandied about on the list, but doesnt get submitted or anything. When a vague concensus has congealed, one of the PDDs is submitted, gets a number, then progresses through the developing-standard track. I just thoght that rather than calling all these phantom PDDs PDD-TBD, authors could give them temporary handles to refer during discusssions, for convenience. But it's not really that important, and I'm happy to drop the idea.
Re: State of PDD 0
On Tuesday 20 February 2001 21:45, Adam Turoff wrote:
PDDs, like the RFCs that preceded them, will need to serve multiple
purposes. One of them will be to catalog (and *name*) ideas that
keep coming up, including the bad ideas (like the |||= operator)
that we're tired of discussing. I don't think anyone expects each
of N PDDs to get us 1/Nth closer to Perl6.
Except it may be possible to keep the RFC structure for the "we're NOT"
historical section. I would much rather have a clean section on "This Is
Perl" than to wade through N + X documents just to glean the N clues that
I'm after.
Some PDDs, especially Informational and possibly Experimental,
might need to precede knowledgeable discussion. If so, then
Standards-track need to have the requirement that they summarize
some amount of discussion on the list(s), and that requirement is
enforcable (i.e., no PDDs out of left field).
Well, we could move to a sponsorship-type model. Since you need a WG Chair
to move it past proposal stage, simply make that a requirement for that
stage too. In order to submit a Standards-track Proposal, you need a WG
Chair, etc, to sponsor it.
That would also allow several people to put together differing proposals
for the times that we don't have prior discussion. Dan, for instance,
could call for proposals for locality handling, and several folks could
write their own comprehensive (ie, no hand-waving "and {poof} magic
happens") PDD of how to implement it. Only one need be accepted, the
others can be archived with all the other Proposals for historical purposes
- that was the whole point in not numbering Proposals in the first place.
But that seems to be merging again with the RFC process - so maybe not.
Of course, if we put too much structure in place, no one will use it, and
we'll either see more non-experimental Experimental PDDs, or no PDDs at all.
That's a good idea, but I'm not entirely convinced that it's the
only one, the fairest one or the most practical one.
I'm all ears. Er... eyes.
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: State of PDD 0
"Bryan C. Warnock" [EMAIL PROTECTED] wrote: Well, there's also Meta stuff for discussion that we should probably document as well. As much as I disliked RFC, I also disliked PDD, as it 'sounds' internal. But do we create a new category for every new area we attempt to document, or do we change the name to reflect something more generic? (The PDD has a Class field to distinguish between internals, meta, and language already.) If we go with mulitple documents, is the numbering scheme concurrent? Sounds good to me. Also, if we go down the 'have a competition to see who can write the best PDD on subject X' path, can we replace the 'TBD' in unnumbered PDDs with a short string chosen by the author? This allows us to (hopefully) unqiuely refer to a document during disussions, but when a final winner is chosen and given a number, the offical library can still pretend the losers never existed, unless people look in the 'losers' section. EG PDD-dapm-GC rather than PDD-TDB for my attempt at garbage collection or whatever.
Re: State of PDD 0
On Wed, Feb 21, 2001 at 07:44:51PM +, David Mitchell wrote: Also, if we go down the 'have a competition to see who can write the best PDD on subject X' path, can we replace the 'TBD' in unnumbered PDDs with a short string chosen by the author? This allows us to (hopefully) unqiuely refer to a document during disussions, but when a final winner is chosen and given a number, the offical library can still pretend the losers never existed, unless people look in the 'losers' section. EG PDD-dapm-GC rather than PDD-TDB for my attempt at garbage collection or whatever. There are advantages with using simple enumeration for RFCs/PDDs. (I'll beat that dead horse only upon request.) The disadvantage of switching to a more descriptive naming scheme is that any identification attached to a PDD upon receipt must be final; a PDD cannot be renumbered/renamed once it has been accepted into the archives. To do so would make it more difficult to search the archives for discussion about an idea -- searching on PDD-std-vtbl won't find the threads that lead to that standard, when it was called PDD-sugalski-vtbl. Perhaps a more descriptive prefix/suffix notation on PDDs would improve upon the anonymous nature of RFCs/PDDs, so long as a core name is assigned to a document never changes. Z.
Re: State of PDD 0
On Tue, Feb 20, 2001 at 02:15:56PM -0700, Nathan Torkington wrote: Bryan C. Warnock writes: Ask, all, are we reusing perl6-rfc as the submittal address, or will there be a new one (perl-pdd)? I'm in favour of renaming to reflect the new use of the list. Dan? How about two lists? I still think that there should be a two-tiered process. I think its a mistake to have a 'one size fits all' process. See my other post on this. Ed
Re: State of PDD 0
At 05:30 PM 2/20/01 -0500, Dan Sugalski wrote: At 02:15 PM 2/20/2001 -0700, Nathan Torkington wrote: Bryan C. Warnock writes: Ask, all, are we reusing perl6-rfc as the submittal address, or will there be a new one (perl-pdd)? I'm in favour of renaming to reflect the new use of the list. Dan? I've been thinking since I sent my last mail on this that we might actually want to leave the two (PDD RFC) separate. Keep on with the RFCs for 'external' things,... I suggest that we clearly delineate the RFCs which were pre-deadline from the ones that are post-deadline. The advantage to having the original deadline was that it motivated many of us to get off our butts and fish or cut bait. If we're going to continue this process now, I move that: New RFCs be numbered starting from 1000 (easiest way to denote the difference); Old RFCs are frozen, and that means frozen. I have no idea how far Larry's got on digesting them and I really don't want to try and interfere with something that could be making its way down his small intestine. People should be free to write new RFCs that contradict older ones, or head off on some tangent, but please let's not keep refining the old ones, enough is enough. -- Peter Scott Pacific Systems Design Technologies
Re: State of PDD 0
On Tue, Feb 20, 2001 at 02:43:14PM -0800, Peter Scott wrote: At 05:30 PM 2/20/01 -0500, Dan Sugalski wrote: At 02:15 PM 2/20/2001 -0700, Nathan Torkington wrote: Bryan C. Warnock writes: Ask, all, are we reusing perl6-rfc as the submittal address, or will there be a new one (perl-pdd)? I'm in favour of renaming to reflect the new use of the list. Dan? I've been thinking since I sent my last mail on this that we might actually want to leave the two (PDD RFC) separate. Keep on with the RFCs for 'external' things,... I suggest that we clearly delineate the RFCs which were pre-deadline from the ones that are post-deadline. The advantage to having the original deadline was that it motivated many of us to get off our butts and fish or cut bait. If we're going to continue this process now, I move that: New RFCs be numbered starting from 1000 (easiest way to denote the difference); Old RFCs are frozen, and that means frozen. I have no idea how far Larry's got on digesting them and I really don't want to try and interfere with something that could be making its way down his small intestine. People should be free to write new RFCs that contradict older ones, or head off on some tangent, but please let's not keep refining the old ones, enough is enough. Strongly agreed. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: State of PDD 0
At 04:43 PM 2/20/2001 -0600, Jarkko Hietaniemi wrote: On Tue, Feb 20, 2001 at 02:43:14PM -0800, Peter Scott wrote: At 05:30 PM 2/20/01 -0500, Dan Sugalski wrote: At 02:15 PM 2/20/2001 -0700, Nathan Torkington wrote: Bryan C. Warnock writes: Ask, all, are we reusing perl6-rfc as the submittal address, or will there be a new one (perl-pdd)? I'm in favour of renaming to reflect the new use of the list. Dan? I've been thinking since I sent my last mail on this that we might actually want to leave the two (PDD RFC) separate. Keep on with the RFCs for 'external' things,... I suggest that we clearly delineate the RFCs which were pre-deadline from the ones that are post-deadline. The advantage to having the original deadline was that it motivated many of us to get off our butts and fish or cut bait. If we're going to continue this process now, I move that: New RFCs be numbered starting from 1000 (easiest way to denote the difference); Old RFCs are frozen, and that means frozen. I have no idea how far Larry's got on digesting them and I really don't want to try and interfere with something that could be making its way down his small intestine. People should be free to write new RFCs that contradict older ones, or head off on some tangent, but please let's not keep refining the old ones, enough is enough. Strongly agreed. That works for me--we could increment the thousands number by one each time we open things up for a new RFC period. Once we have a working perl 6 of some sort we can kick in with RFC 1000, and once perl 6.1 is done we can go with 2000, and so on. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: State of PDD 0
Dan Sugalski writes: I've been thinking since I sent my last mail on this that we might actually want to leave the two (PDD RFC) separate. Keep on with the RFCs for 'external' things, and PDD for the actual internals implementation of things. Ultimately, I think we're going to need at least three different types of documentation: * internals design documents (PDDs) * language design documents (PLDs?) * change requests, once we've got something to change (PCRs) As you can see, I favour getting away from the RFC name. I wish I'd listened to people who warned me about the confusion the name would choose. This also means we don't have to renumber or start counting from 1000 to differentiate the old RFCs from new ones. Nat
Re: State of PDD 0
On Tue, Feb 20, 2001 at 06:17:18PM -0500, Dan Sugalski wrote: At 04:01 PM 2/20/2001 -0700, Nathan Torkington wrote: Dan Sugalski writes: I've been thinking since I sent my last mail on this that we might actually want to leave the two (PDD RFC) separate. Keep on with the RFCs for 'external' things, and PDD for the actual internals implementation of things. Ultimately, I think we're going to need at least three different types of documentation: * internals design documents (PDDs) * language design documents (PLDs?) * change requests, once we've got something to change (PCRs) That works. I rather like it, and I expect once we get a working perl 6, we probably won't need to freeze things either--worst case we mark a proposed document irrelevant or something of the sort. Well, how about calling 'Language Design Documents' "RFC's" ? After all, the term RFC is a lot more generic; it can encorporate comments on *anything* perl related. Ed
Re: State of PDD 0
On Tue, Feb 20, 2001 at 05:42:01PM -0500, Dan Sugalski wrote: At 02:38 PM 2/20/2001 -0800, Ask Bjoern Hansen wrote: How should the submission process work? As for the RFC's? Sounds good to me. Any additional constraints on acceptance criteria? PDD 0 describes an acceptable baseline on rejection (return incomplete submissions), but I daresay that we want something more strict. For example, I doubt that we want or need three competing PDDs on Async I/O developing in the Standard track, but multiple PDDs on the same topic would be welcome if they were Experimental (or even Informational). Would any other constraints help to promote discussion moving forward? The goal isn't to be burdensome on people actually volunteering their time, but to cut down on the crosstalk that doesn't lead to Real Work(tm). Z.
Re: State of PDD 0
On Tuesday 20 February 2001 18:17, Dan Sugalski wrote: Ultimately, I think we're going to need at least three different types of documentation: * internals design documents (PDDs) * language design documents (PLDs?) * change requests, once we've got something to change (PCRs) That works. I rather like it, and I expect once we get a working perl 6, we probably won't need to freeze things either--worst case we mark a proposed document irrelevant or something of the sort. Well, there's also Meta stuff for discussion that we should probably document as well. As much as I disliked RFC, I also disliked PDD, as it 'sounds' internal. But do we create a new category for every new area we attempt to document, or do we change the name to reflect something more generic? (The PDD has a Class field to distinguish between internals, meta, and language already.) If we go with mulitple documents, is the numbering scheme concurrent? I'm also thinking heavily about change requests, and whether they should be separate, or a stage beyond Standard. Pros and cons welcome. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: State of PDD 0
On Tue, 20 Feb 2001, Bryan C. Warnock wrote: On Tuesday 20 February 2001 17:38, Ask Bjoern Hansen wrote: I have created perl6-announce-pdd. Mail [EMAIL PROTECTED] for clues. How should the submission process work? As for the RFC's? Can you confirm the actual submission address? Are we using perl-pdd? And did we want to make this Perl 6 specific, or Perl generic (like perl-qa is)? Notify [EMAIL PROTECTED] after sending the (unnumbered) PDD to perl6-internals and I will add it to the list. Will be changed when the PDD traffic gets higher. - ask -- ask bjoern hansen - http://ask.netcetera.dk/ more than 70M impressions per day, http://valueclick.com
