Re: Proposal for IMPLEMENTATION sections

2000-09-06 Thread David L. Nicol

"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

2000-08-30 Thread Adam Turoff

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

2000-08-30 Thread Mark-Jason Dominus


> 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

2000-08-30 Thread Adam Turoff

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

2000-08-30 Thread Mark-Jason Dominus


> 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

2000-08-30 Thread Adam Turoff

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

2000-08-30 Thread Bryan C . Warnock

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

2000-08-30 Thread Bart Lateur

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

2000-08-29 Thread Nathan Wiger

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

2000-08-29 Thread Tom Hughes

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

2000-08-29 Thread Adam Turoff

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

2000-08-29 Thread Mark-Jason Dominus


> > 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

2000-08-29 Thread John Porter

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.