On Monday 19 February 2001 22:18, Edward Peschko wrote:
> Speaking of which... apologies in advance for cross-posting this, but I
wanted
> to get the largest audience possible... I won't do it again. At least not
in the
> forseeable future.. ;-)
Yes, "forgive me father, for I'm about to sin....."
If it warrants an apology, don't do it.
> I did a brief audit of all of the RFC's, and wheras they were a good
start,
> they are hardly the end-all-be-all for perl6. There were gaps in
functionality,
> a variance in the quality of the RFC's, and not enough emphasis on
> implementation. In addition, the discussion on the list did not seem to
wend
> its way back into the RFC's themselves.
Yes, see below.
> =item 1. that without an RFC process in place, old ideas and discussions
will
> rehash themselves on mailing lists ad nauseum.
Yes.
>
> =item 2. that RFC's are a good starting point for people unfamiliar with
> with discussions/issues on the mailing list.
Yes.
>
> =item 3. that RFC's are a good starting point for documentation.
Yes.
>
> =item 4. that this is perl's first attempt at organizing ideas like this.
> Hence, we are newbies at this and are bound to make mistakes the
first
> time round.
Yes.
>
> However, there is one aspect in which I agree with him. That, as it
stands, the
> RFCs are incomplete, lack encorporation of discussion, and seem to be
'out of
> touch' with the rest of the RFCs (to some extent).
Well, yes, but that was rather the point, wasn't it?
{snip}
> Instead, I think that the doors to the RFCs should be re-opened, and that
they
> should be bulletproofed.
No, and here's why.
The RFC process wasn't meant to be comprehensive or unidirectional - it was
a feeder system for the start of Perl 6. Each RFC wasn't a community
effort, beyond what feedback the author got, and couldn't really be
expected to be complete. Each RFC was also proposed in a vacuum - each
functionality was standalone - unless the author happened to have written
another fifty RFCs or so that they could tie into - so there was no way to
give a true representation of implementation. The RFCs addressed general
models for Perl 6 direction, or directions, since there was no specific
Perl 6 definition to target for. The RFC stage was designed for what folks
were passionate about - the most important changes - not an
all-encompassing picture of Perl 6. It was prep work. It was pre- and
mid-construction bracing. It was just one stage in the life of Perl 6.
It should be left alone as is, if only to segregate all v2 process from the
v1 process.
What you are looking for is the (slightly misnamed) PDD, which I<is>
supposed to be the "end-all-be-all" of Perl 6 (and Perl, to some extent).
It is supposed to a community-driven, comprehensive, living record of what
is (and was) Perl.
http://dev.perl.org/pdd/
> The next four RFCs suggest methods on how to improve
> the RFC process and the quality of RFCs:
>
> RFC 363 - Anyone posting a new RFC should have read all of the existing
> RFCs first.
Anyone posting just about anything should have some historical perspective
to draw from. RFCs, PDDs, mailing lists...
Of course, the problem with the mailing lists is that there are so many
lists, and it's hard to find anything in them anymore. (Unless I'm missing
a search box somewhere for perl6-*)
>
> RFC 364 - There should be a web interface for people to
interactively
> comment on RFCs.
For instance, this was discussed.
>
> RFC 365 - There should be a rating system for RFCs.
As was this.
>
> RFC 366 - There should be a culling system for RFCs, a way to
> distinguish quickly between withdrawn RFCs and RFCs in
> process.
http://dev.perl.org/rfc/by-number.html
>
> (ps -- no, I haven't written these yet. But if this RFC is acted upon, I
reserve
> those numbers in advance. ;-))
Which shows that you haven't read the instructions for submitting an RFC.
:-)
Seriously, though, read PDD 0, and comment on it. No one else has.
(Follow up post coming.)
--
Bryan C. Warnock
[EMAIL PROTECTED]
