From: hensleyl@... (Leslie Hensley)
Date: 2002-01-17T03:55:42+09:00
Subject: Re: RCRCR

Matt Armstrong <matt+dated+200201191053.f7c2b2@lickey.com> wrote in message news:<87advgrftn.fsf@squeaker.lickey.com>...
> matz@ruby-lang.org (Yukihiro Matsumoto) writes:
> 
> 
> > Hi,
>  
> >
>  
> > In message "RCRCR" 
> >     on 02/01/13, David Alan Black <dblack@candle.superlink.net> 
> >     writes:
>  
> >
>  
> > |Yes, a Ruby Change Request Change Request.
>  
> >
>  
> > My only wish for RCR is that I want to discuss about RCR
>  
> >
>  
> > * publicly 
> > * on mail list
>  
> >
>  
> > The current RCR is pull model.  I have to check RCR periodically 
> > (and often forget).  It's little bit annoying and I'd like to 
> > see more public comments.
> 
> 
> I too like the idea of RCR discussion being mainly list based. 
> Here's a nice "life of an RCR" that I think would work well:
> 
> 
> 1. Person has idea.
> 
> 2. Person posts to ruby-talk asking about pros and cons of the 
>    ideas,
> 
>    mentioning possible RCR.
> 
> 3. The idea changes, maybe dies, maybe lives on, after discussion.
> 
> 4. If the idea lives, person creates an RCR on ruby garden.
> 
> 5. Initially, RCR lives in "raw" state -- no comments allowed, 
>    etc.
> 
> 6. RCR moderator makes sure RCR lives up to some quality standards 
>    (i.e. idea has been discussed on list, RCR clearly describes 
>    the change to Ruby and describes the pros and cons, contains 
>    links to relevant ruby-talk posts, Matz has not recently said 
>    he would reject such a change on the list, etc.)
> 
> 7. RCR moderator moves RCR to "open" state, and mail gets sent to 
>    ruby-talk.
> 
> 8. Final discussion happens on rubygarden.org, but this will 
>    likely be short since all major issues are discussed on 
>    ruby-talk already.
> 
> 9. RCR is accepted or rejected.
> 
>  
> Another idea is that bi-weekly mailings to ruby-talk could 
> describe the current "open" RCRs.  This way, it is unlikely that 
> any RCR will stay open for too long.  There are too many undecided 
> RCRs on rubygarden.
> 

While I am not in tune with the ruby community enough yet to comment
on the merits of these approaches, I agree that some sort of RCR
process needs to be put in place.  However I will say that judging
from matz's comment above that the process needs to involve ruby-talk
in some fashion.

> 
> I basically followed this path when I wondered if Regexp#match 
> should take a "character offset to start searching" argument, as 
> an optimization.  It turns out that String#index can do that, so 
> the RCR is unnecessary.  However, the discussion led me to 
> discover that a "character offset" is not what I'd want anyway, 
> for performance reasons with encoded character sets like SJIS and 
> UTF8.
> 
> 
> Another good example is RCR #20 
> (http://www.rubygarden.org/article.php?sid=69).
> 
> 
> Another example is RCR #59 
> (http://www.rubygarden.org/article.php?sid=160).  This should have 
> been discussed on the list first.  I think it is a good idea, but 
> being posted first to rubygarden.org limits its audience.
>

I'm the author of this RCR.  After investigating the RCR process by
browsing the ruby-talk archives, reading the RCR page on the ruby
garden wiki ( http://www.rubygarden.org/ruby?RubyChangeRequest ), and
asking in #ruby-lang I came to the conclusion that the RCR process was
"post it on ruby garden".  I followed this process and judging by the
lack of response to this RCR (and many others) the process is flawed. 
In the absence of a reformed process I will be posting a pointer to
this RCR to ruby-talk in hopes of jump starting its progress.

> 
> Examples of recent bad RCRs are #58 and #57.  The changes 
> requested are not clearly described, and would have been much 
> better to post to ruby-talk soliciting comments first.  So they 
> would have benefited from the above process.