From: David Alan Black <dblack@...>
Date: 2002-01-13T13:28:27+09:00
Subject: Re: RCRCR

Hello --

On Sun, 13 Jan 2002, John Wheeler wrote:

> "David Alan Black" <dblack@candle.superlink.net> wrote in message
> news:Pine.LNX.4.30.0201121329160.2980-100000@candle.superlink.net...
>
> > Yes, a Ruby Change Request Change Request.
> >
> > It seems to me that RCRs fall into several categories, and that those
> > categories are different enough from each other that it would be worth
> > turning them into different things.
>
> Hi,
>
> I am not one to say that the US government might have the right
> answer, but my background is in US DoD configuration management. So,
> here is my 2 cents on this one.

  [Interesting but, to me, not very Ruby-world-scaleable/applicable
   info on how the DoD does things elided.]

> Enough tirade, what am I suggesting?
>
> 1. That a single RCR process will address the needs of the Ruby
>    community better than creating multiple change processes that depend on
>    the desired outcome of the change.
>
> 2. That any change request system that forces the change requester to
>    be as knowledgeable as the system developers is missing part of the
>    point of allowing change requests in the first place.  That point is to
>    gather as many good ideas as possible from anyone who is willing talk
>    about it.

(I still don't think that people who don't know whether they're adding
or changing a method should be writing RCRs, if that's what you're
getting at :-)

This is probably all getting more convoluted than it needs to be.  The
original RCRCR was pretty simple, and wouldn't change anything about
what did or did not reach Matz, or who could or could not submit RCRs.
It would mainly just differentiate between asking Matz to change Ruby
in a non-backward-compatible way, and asking Matz to add some new,
backward-compatible functionality to Ruby.  People already ask for
both; I'm only suggesting that the difference be made clear on input
into the queue.

Principally this would make possible multiple views of the queue.
Right now there's only one view.  That view would still be available
-- but it would also become possible to look at the RCRs and
determine, for example, which ones were additive ("enhancements") and
might lend themselves to implementation and distribution outside of
the loop of the RCR process.  (One can determine that now, but only by
sifting through them.)

It's also conceivable that asking people to think about how their RCR
relates to the language might lead people, in some cases, to realize
that their RCR is something they could just write and distribute,
without its having to be added to the core language.

Well, I suppose having the RCR queue be cluttered and unsorted at
least means that a certain amount of clutter and unsortedness are
confined to one place :-)  And we're not (yet) talking about all that
much material -- I don't think there's more than about 100 of them.
Pre-organizing them a little just strikes me as a fairly cheap way to
gain a little (and possibly more than a little, eventually) clarity.


David

-- 
David Alan Black
home: dblack@candle.superlink.net
work: blackdav@shu.edu
Web:  http://pirate.shu.edu/~blackdav