Re: RFC - Prototype RFC Implementations - Seperating the men from the boys.

[Adam Turoff]

On Fri, Sep 15, 2000 at 04:11:27PM -0600, Nathan Torkington wrote:
 Mark-Jason Dominus writes:
  I think it would be a step in the right direction if the WG chairs
  actually required RFC authors to maintain their RFCs.
 
 In preparation for the end-run of RFCing, how about we compile a list
 of "developing" RFCs that haven't been touched in more than a week,
 and contact the authors to say "last chance, please finish up your
 RFC now."
 
 Such a program would be easy to write (praise be to Date::Parse) and
 would hopefully prod authors into incorporating feedback and closing
 out their RFCs.
 
 Good idea?

[time passes]

I didn't use Date::Parse, but I did look for all RFCs still stting
at v1 status.  Since they're numbered chronologically, I cut off the
bottom (anything submitted after 9/7).

There are 100 RFCs in the list that follows.  Code and data upon request.

Z.

-


RFC  : 3 v1; [Developing]
Title: messages.rfc - An RFC to discussing the wisdom of allowing run time error and 
warning messages to be modified at run time
Maint: Corwin Brust [EMAIL PROTECTED]
List : [EMAIL PROTECTED]
Date : 1 Aug 2000

RFC  : 7 v1; [Developing]
Title: Higher resolution time values
Maint: Gisle Aas [EMAIL PROTECTED]
List : [EMAIL PROTECTED]
Date : 2000-08-02

RFC  : 9 v1.0; [Developing]
Title: Highlander Variable Types
Maint: Andy Wardley [EMAIL PROTECTED]
List : [EMAIL PROTECTED]
Date : 01 Aug 2000

RFC  : 11 v1; [Developing]
Title: Examples encoded with =also for|begin|end POD commands
Maint: Barrie Slaymaker [EMAIL PROTECTED]
List : [EMAIL PROTECTED]
Date : 02 Aug 2000

RFC  : 12 v1; [Developing]
Title: variable usage warnings
Maint: Steve Fink [EMAIL PROTECTED] for now
List : [EMAIL PROTECTED]
Date : 2 Aug 2000

RFC  : 13 v1; [Developing]
Title: Creation of Copyright and Licensing Working Group
Maint: SBradley M. Kuhn Elt[EMAIL PROTECTED]gt
List : [EMAIL PROTECTED]
Date : 2 Aug 2000

RFC  : 15 v1; [Developing]
Title: Stronger typing through tie.
Maint: Michael Fowler [EMAIL PROTECTED]
List : [EMAIL PROTECTED]
Date : 02 August 2000

RFC  : 16 v1; [Developing]
Title: Keep default Perl free of constraints such as warnings and strict.
Maint: Daniel Chetlin [EMAIL PROTECTED]
List : [EMAIL PROTECTED]
Date : 3 Aug 2000

RFC  : 18 v1; [Developing]
Title: Immediate subroutines
Maint: Jean-Louis Leroy
List : [EMAIL PROTECTED]
Date : 04 Aug 2000

RFC  : 19 v1; [Developing]
Title: Rename the Clocal operator
Maint: J. David Blackstone [EMAIL PROTECTED]
List : [EMAIL PROTECTED]
Date : 4 Aug 2000

RFC  : 20 v1; [Developing]
Title: Overloadable  and ||
Maint: Jean-Louis Leroy
List : [EMAIL PROTECTED]
Date : 04 Aug 2000

RFC  : 21 v1.00; [Developing]
Title: Replace Cwantarray with a generic Cwant function
Maint: Damian Conway [EMAIL PROTECTED]
List : [EMAIL PROTECTED]
Date : 4 August 2000

RFC  : 22 v1.00; [Developing]
Title: Builtin switch statement
Maint: Damian Conway [EMAIL PROTECTED]
List : [EMAIL PROTECTED]
Date : 4 August 2000

RFC  : 24 v1.00; [Developing]
Title: Semi-finite (lazy) lists
Maint: Damian Conway [EMAIL PROTECTED]
List : [EMAIL PROTECTED]
Date : 4 August 2000

RFC  : 25 v1.00; [Developing]
Title: Multiway comparisons
Maint: Damian Conway [EMAIL PROTECTED]
List : [EMAIL PROTECTED]
Date : 4 August 2000

RFC  : 27 v1; [Developing]
Title: Coroutines for Perl
Maint: Tom Scola [EMAIL PROTECTED]
List : [EMAIL PROTECTED]
Date : 04 Aug 2000

RFC  : 28 v1 ; [Developing]
Title: Perl should stay Perl.
Maint: Simon Cozens [EMAIL PROTECTED]
List : [EMAIL PROTECTED]
Date : Aug 4 2000 

RFC  : 31 v1.00; [Developing]
Title: Co-routines
Maint: Damian Conway [EMAIL PROTECTED]
List : [EMAIL PROTECTED]
Date : 4 August 2000

RFC  : 32 v1; [Developing]
Title: A method of allowing foreign objects in perl
Maint: Dan Sugalski [EMAIL PROTECTED]
List : [EMAIL PROTECTED]
Date : August 02, 2000

RFC  : 35 v1; [Developing]
Title: A proposed internal base format for perl variables
Maint: Dan Sugalski [EMAIL PROTECTED]
List : [EMAIL PROTECTED]
Date : August 04, 2000

RFC  : 36 v1; [Developing]
Title: Structured Internal Representation of Filenames
Maint: Jarkko Hietaniemi [EMAIL PROTECTED]
List : [EMAIL PROTECTED]
Date : 04 Aug 2000

RFC  : 40 v1; [Developing]
Title: Module Scope Control
Maint: Bryan C. Warnock [EMAIL PROTECTED]
List : [EMAIL PROTECTED]
Date : 5 Aug 2000

RFC  : 43 v1; [Developing]
Title: Integrate BigInts (and BigRats) Support Tightly With The Basic Scalars
Maint: Jarkko Hietaniemi [EMAIL PROTECTED]
List : [EMAIL PROTECTED]
Date : 05 Aug 2000

RFC  : 44 v1; [Developing]
Title: Bring Documentation Closer To Whatever It Documents
Maint: Jarkko Hietaniemi [EMAIL PROTECTED]
List : [EMAIL PROTECTED]
Date : 05 Aug 2000

RFC  : 46 v1; [Developing]
Title: Use features of portable, free compilers and libraries
Maint: John Tobey [EMAIL PROTECTED]
List : [EMAIL PROTECTED]
Date : 5 Aug 2000

RFC  : 47 v1; [Developing]
Title: Universal Asynchronous I/O
Maint: Uri Guttman [EMAIL PROTECTED]
List : [EMAIL PROTECTED]
Date : 05 Aug 2000

Re: RFC - Prototype RFC Implementations - Seperating the men from the boys.

[John Porter]

Michael G Schwern wrote:
 Chaim Frenkel wrote:
  
  At this point, I think this is too strong. My understanding of Larry's
  intention is that we are now brainstorming. Brainstorming can not work
  if folks will pre-filter their ideas. Part of the effect is a half-baked
  idea on another member of the brainstorming group. (I've seen some of
  the effect in Damian's responses)
 
 "RFCs should be *FOLLOWED BY* a prototype implementation"
 
 "...each RFC should *EVENTUALLY* be accompanyed by a prototype
 implementation"
 
 I'm not stating that each RFC should come with a prototype, but that
 one should be forthcoming as part of its development process.
 
 "If the RFC author feels they cannot implement the prototype on their
 own, they must find people who can.  If they can't then they're not
 going to be able to find those to implement the actual code either."
 
 If you can't find the tuits to write the prototype, how are you going
 to find them to write the implementation?

No.  You can not oblige the RFC maintainer to write the prototype or
cat-herd someone else into it.  The vast majority of RFC authors
(myself included) would simply not be up to such an order.

Instead, it should be the WG lead's responsibility to ensure that each
accepted RFC gets a prototype (*EVENTUALLY*), assigning an implementor
if necessary.


-- 
John Porter

We're building the house of the future together.

Re: RFC - Prototype RFC Implementations - Seperating the men from the boys.

[Dan Sugalski]

At 05:30 PM 9/11/00 -0400, Chaim Frenkel wrote:
Up until that point, it is wasted energy. At this point, without code
there is nothing locked down, no cost in changing. (Yes, even though
they are bits, changing software, changing architecture has major
costs.)

Don't forget that changing architecture has costs, even without code 
backing it yet. There's still the mental costs of refiguring how it all 
fits together. (And it does all need to fit together--if the mental model's 
a kludged up hack, the implementation will be too)

This isn't to argue against making changes and reworking things, mind. Just 
pointing out that all changes have a cost.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk