Re: [Gnu-arch-users] [ATTENTION PLEASE] standards process

[Stephen J. Turnbull]

A bit behind on my reading ....

>>>>> "Tom" == Tom Lord <address@hidden> writes:

    Tom> First, I believe that it would be good (generally useful,
    Tom> fun) if there existed some "standards documents", blessed by
    Tom> *some* ritual, which are the "official" definition of (at
    Tom> least) core arch.

Also, SRFI'S are treated as features (SRFI 7).  Probably too coarse
for the needs of Pyarch, though.

    Tom> Second, I'd like to create a "destination point" forum for
    Tom> otherwise neverending design discussions on g-a-u.  When a
    Tom> topic is being talked to death, either it can be dropped, or
    Tom> someone can take the effort of moving it to the next level (a
    Tom> lightly ritualized design proposal/defense stage).

Taking asuffield's characterization PEP process == SRFI process as a
good approximation[1], that is not the way it works in practice.

Rather, (1) the formal process typically gets started by a proponent
early in the discussion (proves seriousness), and (2) controversial
proposals get talked to death anyway.  The difference between this and
"never-ending design discussions" is that _the basic idea and most of
the good and bad aspects get documented_.

This means that the large number of discussions that get interrupted
and restarted restart from a common point, even when the impetus to
restart is a big jump from the point of interruption.  Everybody has
the same coordinates in hyperspace, so to speak.

    Tom> The minimal thing is that I'm goign to write some formal
    Tom> specs, one way or another.  If a SRFI-like thing is too
    Tom> heavyweight for this stage (which it sounds like it is) I can
    Tom> find another (and probably simpler) way.

[nb I have not seen ddaa's post, only asuffield's saying it had no
content worth quoting.  Forgive me if I repeat some.]

I don't see why it need to be.  You need somebody you and the other
core developers trust to be editor.  They don't need to be all that
competent in arch development---somebody like me would be a good
candidate (except that I probably don't clear the "trust" hurdle for
some of the important developers).  Having an editor is not that big a
requirement.

Both the SRFI and PEP standards recommend that discussion be focused.
SRFI mandates this with a separate mailing list; I think that is too
heavyweight for arch.  PEP by contrast _requires_ discussion on the
general channels before finalizing, but _recommends_ some explicit
focus for discussion, such as creating a list.  That seems more
archaic (to coin a term).

SRFI specifies a lot of deadlines in terms of calendar time.  I think
the PEP process, which rather says "OK, please produce a document or
shut up", and later "produce an implementation or admit you're going
nowhere" is more in keeping with arch's current (implicit) process.

I like ReST (or POD if you prefer, though I don't know much about
POD's spec) if you like.  HTML sucks.  A minor detail.

I think having a process people can refer to when making proposals,
and a document archive separate from the mailing list, is a good idea.
I think having a document which summarizes the current state of the
discussion is very important.  One of the uses of the PEPs is for
people to say "that's in the PEP; what do you have to say to add to
that?"  The discussion may still never end, but it tends to be more
informative.

As you implicitly observe, you don't _need_ that process to produce
good proposals.  But others may.  Several of the proposals posted
recently have run out of steam midway; somebody (maybe it was ddaa)
actually wrote "I'm tired of writing, you're tired of reading, so I'm
just going to sketch the rest."  Nothing wrong with that, if things
get properly fleshed out before implementation.  The mailing list
format discourages it, though, even you eventually got sick of dealing
with the discussions about xl and furth.  Having a separate, more
formal document encourages completion, both of original drafts and of
updates---or total abandonment, if the idea is going to collapse of
its own weight.  That's what should happen.

Dunno about SRFI, but PEP has always been more honored in the breach
than the observance.  As Python gathered momentum and financial
backing, people have taken it more seriously.  But there are still
gaps.  You could adopt either process as a model but say "until we get
more experience, the following aspects of the ARFI process are to be
taken with a grain of salt: (1) ... (2) ... (3) ....  Feel free to
propose changes to the process definition, aka ARFI 0."

You do need an editor to manage the ARFI archive and to help people
_format_ the documents, and you (and other leaders) need to commit to
being somewhat familiar with current ARFIs so you can say "it's in the
ARFI, what new things do you have to say?"  Everything else is fairly
optional.


Footnotes: 
[1]  I've observed the PEP process closely for several years, as well
as being familiar with the definition document.  Neither is true of
the SRFI process.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.