Re: Proposal for IMPLEMENTATION sections
"Bryan C. Warnock" wrote: > > It's hitting a moving target :-( I continue to explain myself until my mistakes become clear, that's why I'm often wrong.
Re: Proposal for IMPLEMENTATION sections
On Wed, Aug 30, 2000 at 04:04:03PM -0400, Mark-Jason Dominus wrote: > > Suppose a WGC establishes a requirement for the solidity of the > implementation section, and receives an RFC that does not meet the > requirements. What then? > If the WGC chair sets forth explicit requirements as to what goes into the implementation section, then any RFC that does not meet those requirements will be put on hold or rejected for cause and sent back to the author (with a CC to the WGC). Currently, any RFCs that do not meet the low formatting requirements are put on hold or rejected for cause and sent back to the author. In both cases, an RFC will be accepted when fixed. Ditto for other requirements. Starting tomorrow, Status: fields will be manditory, and all new RFCs will default to 'Status: Developing' if omitted. Z.
Re: Proposal for IMPLEMENTATION sections
> On Wed, Aug 30, 2000 at 02:29:33PM -0400, Mark-Jason Dominus wrote: > > > > > Any requirements on how solid an implementation section should be > > > should be left to the working group chairs. > > > > Sorry, I don't understand this. What is the WGC's role here? > > My english native language is? :-) I didn't have problem with the parsing. I had trouble with the meaning. Suppose a WGC establishes a requirement for the solidity of the implementation section, and receives an RFC that does not meet the requirements. What then?
Re: Proposal for IMPLEMENTATION sections
On Wed, Aug 30, 2000 at 02:29:33PM -0400, Mark-Jason Dominus wrote: > > > Any requirements on how solid an implementation section should be > > should be left to the working group chairs. > > Sorry, I don't understand this. What is the WGC's role here? My english native language is? :-) I meant to say that if there are to be more stringent requirements as to what should be in an implementation section, I leave that decision to the WGC. It's not the job of the librarian to reject an RFC because it lacks sample code, but if the WGC wants to be stricter, I will try and abide on a per-group basis. Z.
Re: Proposal for IMPLEMENTATION sections
> Any requirements on how solid an implementation section should be > should be left to the working group chairs. Sorry, I don't understand this. What is the WGC's role here?
Re: Proposal for IMPLEMENTATION sections
On Tue, Aug 29, 2000 at 07:34:10PM -0700, Nathan Wiger wrote: > Mark-Jason Dominus wrote: > > > > The IMPLEMENTATION section of the RFC is supposed to be mandatory, but > > there have been an awful lot of RFCs posted that have missing or > > evasive IMPLEMENTATION sections. > > Well, I have to counter this with the following: Having a complete > IMPLEMENTATION section should wait until at least v3. Then there are the "position paper" RFCs that don't require an implementation. Simon's RFC 28: 'Perl should stay Perl' is a perfect example. And don't forget the "really cool new ideas" where a discussion of implementation is premature, like Damian's RFC 21: 'Replace C with a generic C function'. Both of these should have a stub, but should never be expected to have a full implementation, v3 or otherwise. > So I would say, v1's and v2's should get some slack. If the idea's still > around by v3, then IMPLEMENTATION should be considered. But doing this > before them is a waste of time, IMO. Yes, there should be some slack, but not on the reqirement to have an implementation section. I would hope from here on out, RFC authors spend a modicum of time writing up why an idea doesn't need an implemenation, why such discussions are premature, or why the author needs help writing it up. Any requirements on how solid an implementation section should be should be left to the working group chairs. Z.
Re: Proposal for IMPLEMENTATION sections
On Tue, 29 Aug 2000, Mark-Jason Dominus wrote: > Not everyone knows enough about Perl's internal design or about > programming design generally to be able to consider the issues. I > suggest that these people should write to the approrpriate working > group chair and ask to be put in touch with someone who can help them > with the internals sections of their RFC. Then they can work out some > of the details together and we might avoid some of the more obviously > half-baked suggestions. Which was more or less the point of the RFC process, no? Throw an idea out there (in RFC format, as requested), and garner the pros and cons. In some cases, the RFCs are simply a formalization of a lot of unsubstantial discussion - everyone things that "foo" should do "bar" - but no one knows how. At least get that request documented. The internal RFCs have become a little difficult, at least for me, to write a full implementation section on. Why? Because I don't know enough about Perl 6 internals. But oddly enough, neither does anyone else, because there aren't any. Yet. It's hitting a moving target - much like what the entire RFC process has become. :-( -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: Proposal for IMPLEMENTATION sections
On Tue, 29 Aug 2000 17:54:17 -0400, Mark-Jason Dominus wrote: >The IMPLEMENTATION section of the RFC is supposed to be mandatory, but >there have been an awful lot of RFCs posted that have missing or >evasive IMPLEMENTATION sections. I found more than 39% of all RFCs >have a missing or incomplete implementation section. There's a reason why -language and -internals are separate lists. (duck and run). -- Bart.
Re: Proposal for IMPLEMENTATION sections
Mark-Jason Dominus wrote: > > The IMPLEMENTATION section of the RFC is supposed to be mandatory, but > there have been an awful lot of RFCs posted that have missing or > evasive IMPLEMENTATION sections. Well, I have to counter this with the following: Having a complete IMPLEMENTATION section should wait until at least v3. Why? Because many of the v1's get dumped or revised heavily. By v2, most are either 90% of the way there or retracted. By v3, I think it's time to get "down and dirty" and start figuring it out. So I would say, v1's and v2's should get some slack. If the idea's still around by v3, then IMPLEMENTATION should be considered. But doing this before them is a waste of time, IMO. -Nate
Re: Proposal for IMPLEMENTATION sections
In message <[EMAIL PROTECTED]> Mark-Jason Dominus <[EMAIL PROTECTED]> wrote: > RFCs: 21 26 62 84 88 110 112 131 136 137 140 149 162 165 166 > > These 15 ( 9%) had no IMPLEMENTATION section at all. I was > surprised that the librarian had even accepted these, since > that section is not described as 'optional' in the RFC format > document. As the author of RFC 136 this is an interesting issue. I did actually think about this question when writing it, and made a conscious descision to remove when I realised that, as an suggestion for an implementation of part of the internals, the DESCRIPTION section had actually discussed the implementation issues. In fact I would have thought that for many internals RFCs the whole topic of the RFC is how to implement something. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/ ...I like to enter messages from the Asylum computer.
Re: Proposal for IMPLEMENTATION sections
On Tue, Aug 29, 2000 at 06:26:29PM -0400, Mark-Jason Dominus wrote: > > I'd like to amend my proposal. Suppose that the librarian *suggests* > that RFC authors contact the WG chair when they submit RFCs that omit > the implementation section? That way nobody is forced to do anything, > and many people might be grateful for the service. > Consider this done, starting 9/1. Status headers will become manditory as well. There are about 25 RFCs and updates in the queue at the moment that should be exempt. Waiting until Friday gives everyone at least one day's notice. The dev.perl.org/rfc/meta section is long overdue for an update. Thanks to everyone who has sent patches, recommendations, and questions about the RFC format. I hope to get to it this afternoon, after posting today's lot of RFCs. Note that this does NOT mean that RFCs will be rejected outright. To date, authors of incomplete RFCs have been contacted when their submissions cannot be posted as-is, so that their submissions may be completed. Z.
Re: Proposal for IMPLEMENTATION sections
> > These 13 ( 8%) had very brief IMPLEMENTATION sections that > > didn't contain any substantive discussion. > > > > These 21 (13%) contained remarks about the author's ignorance. > > > > These 15 ( 9%) had no IMPLEMENTATION section at all. > > The distinction between these three cases is arbitrary and trivial, > being as they are more a reflection of the authors' tastes. No, that is not true. The distinction between the first two groups is trivial. The third group is a group of RFCs that were published even though the supposedly required section was omitted. I mentioned the remarks about the authors' ignorance because it seemed to me that these were people who might have appreciated being hooked up with someone who could help make their RFCs stronger. > I wish you had applied the standard more evenly; imho, 97 & 100 had > good reasons for their cursory treatments of implementation. Sorry. I should have put in a disclaimer that I did the survey very quickly and I didn't try to be consistent. The important point of the survey was that many RFCs that should have implementation sections lack them. The details about why the section was omitted are there mostly to pander to curiosity. I'd like to amend my proposal. Suppose that the librarian *suggests* that RFC authors contact the WG chair when they submit RFCs that omit the implementation section? That way nobody is forced to do anything, and many people might be grateful for the service.
Re: Proposal for IMPLEMENTATION sections
Mark-Jason Dominus wrote: > > These 13 ( 8%) had very brief IMPLEMENTATION sections that > didn't contain any substantive discussion. > > These 21 (13%) contained remarks about the author's ignorance. > > These 15 ( 9%) had no IMPLEMENTATION section at all. The distinction between these three cases is arbitrary and trivial, being as they are more a reflection of the authors' tastes. > RFCs: 97 100 > > These 2 ( 1%) said that implementation discussion was beyond > the scope of the RFC, which I don't understand, since it > clearly *is* part of the scope of the RFC. > > RFCs: 7 16 33 34 68 74 76 77 91 94 102 107 114 118 121 144 > > These 16 (10%) said something along the lines of "The > implementation should be straightforward." I did not try to > judge whether this was actually true. I wish you had applied the standard more evenly; imho, 97 & 100 had good reasons for their cursory treatments of implementation. > Not everyone knows enough about Perl's internal design or about > programming design generally to be able to consider the issues. I > suggest that these people should write to the approrpriate working > group chair and ask to be put in touch with someone who can help them > with the internals sections of their RFC. I respectfully register my dissenting opinion. It's what "RFC" means. However, the status of each RFC ought to be shown on the main RFC index; and withdrawn (or otherwise euthanized) RFCs should be removed from thence, perhaps to another, archival page. -- John Porter We're building the house of the future together.
