From: John Wheeler <jwheeler@...>
Date: 2002-01-13T12:47:15+09:00
Subject: Re: RCRCR


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

The US DoD manages to *squeak* by using only two kinds of change
requests. One, a Class I change, addresses changes that will affect
form, fit, or function of the affected system. (Read that: "things that
break other things.")  The other, a Class II change, is for everything
else.  Both of these changes are suggested on a single form and, with
one minor exception, are handled by the same process.  That exception is
that very often the system developers are allowed to act on Class II
changes before everyone gets involved in the decision process.

The really great thing about using a single form and a uniform process
for all change requests is that this allows everyone, from the system
developer to the lowly user in the field, to use a single form and
process when he needs something changed. It also gives the folks who
control the system configuration a single point of control.  Instead
of looking in one change queue for *required major improvements* and
in another queue for *urgent minor tweaks*, it forces all proposed
changes to the attention of those in control.  True, they might end up
with a big queue that way, but, as long as there is only one
configuration managing body, that body will have to address all
changes anyway, large and small.

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.

John  Wheeler