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

[Tom Lord]

This is a great post and I wanted to apply my highlight marker by
(mostly) just sticking it in the archive twice.

Some observations:

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

Further evidence that you are right is that the calendar deadlines in
SRFI are mostly honored in their breach.   I think they *might* be
useful the same way that drug laws are (at the momement, while we
remain a fundamentally immature society) useful in practice:  they are
handy for cutting off people who are obviously gaming the system.


    > As you implicitly observe, you don't _need_ that process to
    > produce good proposals.  But others may.

I'm privileged by circumstance and therefore don't *personally* need
the structure all that much (in the medium term).   But, in general, 
a little formality gives all of us (me included) a clear goal -- a
clear bar to get over.


    > Dunno about SRFI, but PEP has always been more honored in the
    > breach than the observance.

SFRI, likewise.  The calendar hack is a nice arbitrary way for editors
to say "This doesn't seem to be converging on a right-form thing".   

Such judgement by the editors doesn't shut down work --- it just
bounds the public forum around work that might not be ready for prime
time yet.

    > You do need an editor to manage the ARFI archive and to help people
    > _format_ the documents, 

That's the biggest thing --- the biggest problem.    I'm pretty sure
we aren't there yet in terms of available expert volunteerism.   I
sure wouldn't want to try to, for example, pull abentley off of 
builder work to be an editor.

The expert Scheme community is rather larger than the expert arch
community.

-t




    > X-42-Pre-Check: Attempted
    > Cc: address@hidden
    > Organization: The XEmacs Project
    > From: "Stephen J. Turnbull" <address@hidden>
    > Date: Thu, 09 Sep 2004 19:14:38 +0900
    > User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.5 (chayote, linux)
    > Content-Type: text/plain; charset=us-ascii
    > Sender: "Stephen J. Turnbull" <address@hidden>
    > X-Spam-Checker-Version: SpamAssassin 2.64-42mail (2004-01-11) on 
    >   mail.42inc.com
    > X-Spam-DCC: dcc.uncw.edu: mail 1201; Body=1 Fuz1=1 Fuz2=1
    > X-Spam-Status: No, hits=-4.9 required=4.5 tests=BAYES_00 autolearn=ham 
    >   version=2.64-42mail
    > X-42email-MailScanner-Information: Please contact 
http://www.42inc.com/support.html for more information.
    > X-42email-MailScanner: Found to be clean
    > X-UIDL: 0f7893b798c2609ec70dc4440e1a1ed4
    > 
    > 
    > 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.
    > 
    >