Perhaps another point of view will help. I'm the maintainer of RFC 88: Omnibus Structured Exception/Error Handling Mechanism (as at http://tmtowtdi.perl.org/rfc/88.html). My experience of the RFC process was good to very-good; some would rate the process fair to good. I don't think it deserves a poor or an excellent. The mechanism proposed by RFC 88 is *much* better than was the one I started with, solely as a result of the input from those who contributed to the topic. I had a good head of steam up going in, because this is a pet topic of mine, and because we have been using a similar mechanism in-house with Perl 5. But as is often the case, showing the work to others interested in the topic produced numerous good-to-excellent suggestions for both enhancements and for simplifications. In the case of RFC 88, this must be considered to be the overwhelming result. Overall, I think that the single change that would have had the greatest effect on the quality of the whole RFC effort would have been to run the RFC process over six months. I spent over 200 hours on RFC 88, I sent ~150 messages to the mailing list, and the RFC ended up thirty printed pages long. There was hardly time to think. I couldn't have done it if hadn't been the dog days of August during a slow spot in my job. I can understand how those who attempted more than one or two RFCs in the allotted time would have been unable to be so complete in each such RFC. And I understand that such a long period would have produced other problems. RFC 88 began life as a counter-proposal to Peter Scott's RFC 63 (Exception Handling Syntax) initially because I though we should separate exception "objects" from exception handling. I also authored RFC 96 (A Base Class for Exception Objects), to compliment 88, but it ended up being similar to Peter's RFC 80 (Exception Objects and Classes for Builtins) which he published at about the same time. It turns out that Peter and I had quite similar approaches, and so over time he withdrew RFC 63 and became co-author of RFC 88. I withdrew RFC 96, and we delegated the details for builtins to RFC 80 (which is maintained by Peter). So we ended up with two RFCs, 88 on exception handling and generic exception objects, and 80 on how exception objects should be used for exceptions in builtins. I think the process was quite effective here. I think that having a separate (if misnamed) mailing list for "errors" and exceptions was, in this case, effective. Since RFC 88 was based on an existing Perl 5 implementation, it was quite straightforward for us to build a complete simulation of the proposed implementation (modulo syntactic details) based on using C<die> and C<eval> as primitives, and to provide regression tests thereto (as at http://www.avrasoft.com/perl6/try6-ref5.txt). I understand that such an approach to IMPLEMENTATION DETAILS may not be applicable to all other RFCs (but don't underestimate the value to all of being able to point to the code and regression tests and say, "um, yes, it does actually work" ;-) With the prodding and help of Peter and the other contributors, RFC 88 ended up containing quite a detailed review of the issues raised and discussed during the RFC process. We probably would have better results if all other maintainers had simply kept a folder of the mail relevant to their RFC and summarized it before freezing. Note though that at one point concern was raised as to whether or not RFC 88 was simply getting too big, because of all this documentation. There were of course the usual problems inherent in conducting technical discussion via a mailing list (but I developed a thick skin in comp.lang.c in c.1987 ;-) Here are a few notes thereto that may be of interest to archeologists or the designers of the next RFC process (if any). * Not all readers are familiar with every topic. Provide enough introductory explanation of what you are proposing, and why, to help those readers avoid unnecessary "requests for information". Don't put the technical details of a proposal before the explanation, because that will apparently prevent some readers from proceeding to the explanation before "requesting additional information". * A great deal of heat, and some light, was generated by concerns that imposition of RFC 88 in and of itself would change the very nature of what we know as love as Perl. That wasn't the case, but quite some effort was devoted to the matter in spite of that. The lesson is: don't underestimate the importance of the IMPACT section, and if appropriate, state your disclaimers up front. * There was the usual confusion caused by those whose experience with exception handling was limited to its use for error handling, and by those who only had experience with exception handling in one or two other languages. Here again considerable effort was devoted to alleviating those concerns in the RFC. * The usual tension between theoreticians and pragmatists, and between scripters, application developers, and framework developers, was apparent. RFCs would do well to address these issues when they are promulgated. Perhaps if there had been a longer period over which the RFCs could have matured, we would have had more opportunity for "natural" topic architects to emerge, after which they could have merged alternative contributions into a whole, properly covering the issues discussed above and elsewhere. I would have liked to contribute more to the OO topic than just RFC 92 (Extensible Meta-Object Protocol), but fortunately Damian effectively held the architecture chair thereto, so I could relax. Similarly, with more time I imagine more complete proposals for things like functional operations and continuations could have matured. Having said all this, I wouldn't complain about the whole thing too much. I can certainly point to any number of mailing lists where the discussions would not have gone anywhere nearly as well! (And don't forget that all this dynamic tension is part of the fun of lightweight process methodologies ;-) Thanks again to Peter Scott, Graham Barr, Chaim Frenkel, Jonathan Scott Duff, Glenn Lindermann, Dave Rolsky, Corwin Brust, Jim Hoover, and the Software Engineering Research Lab at the University of Alberta, for your contributions to RFC 88. Yours, &c, Tony Olekshy
