<much deleted> As much as I'd like to respond to some of these points, I'll refrain from it now, I'll let my RFCs speak for themselves. 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.. ;-) Ed RFC 362 ------- =head1 TITLE The RFC project should be ongoing and more adaptive. =head1 VERSION Maintainer: Edward S. Peschko <[EMAIL PROTECTED]> Date: 19 Feb 2001 Mailing List: [EMAIL PROTECTED] Number: 362 Version: 1 Status: Developing =head1 ABSTRACT The RFC process should not have had an artificial deadline; it should be an adaptive process that should last the entire development cycle of perl6 and perhaps after. =head1 DESCRIPTION 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. Mark Dominus went so far to post a critique of the entire process: http://www.perl.com/pub/2000/11/perl6rfc.html and to conclude that the whole "RFC's process" was pretty much a waste of time for the quality of RFC's produced. Well, that's one view - but it neglects to recognize: =item 1. that without an RFC process in place, old ideas and discussions will rehash themselves on mailing lists ad nauseum. =item 2. that RFC's are a good starting point for people unfamiliar with with discussions/issues on the mailing list. =item 3. that RFC's are a good starting point for documentation. =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. 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). But that just points out to me the validity of point #4 above; we are new at this. We would get better as we go along. In addition, right now (as of February), I get the sense on the mailing lists that people don't really know what to do next. 'Wait for Larry' seems to be the order of the day, and we have been waiting for a while. Instead, I think that the doors to the RFCs should be re-opened, and that they should be bulletproofed. 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. RFC 364 - There should be a web interface for people to interactively comment on RFCs. RFC 365 - There should be a rating system for RFCs. RFC 366 - There should be a culling system for RFCs, a way to distinguish quickly between withdrawn RFCs and RFCs in process. (ps -- no, I haven't written these yet. But if this RFC is acted upon, I reserve those numbers in advance. ;-)) =head1 IMPLEMENTATION Not really an implementation thing, more of a philosophy and process. =head1 REFERENCES http://www.perl.com/pub/2000/11/perl6rfc.html http://www.perl.com/pub/2000/11/jarkko.html
