Re: Scheme RFCs

[Alan Bawden <Alan@lcs.mit.edu>]

   Date: Tue, 17 Nov 1998 11:14:44 -0500 (EST)
   From: Marc Feeley <feeley@iro.umontreal.ca>

   > In my proposal for the "if-implements" construct I allow the
   > feature-identifier to be the name of the SRFI, e.g. SRFI-123, or an
   > alias that is specified with the SRFI, such as Unicode-IO.  Thus an
   > alias field should be added to the SRFI document format.

   Since the SRFI-0 proposal seems relevant to the discussion of the
   SRFI process, I am attaching the current draft of the SRFI-0 proposal.

Wait!  Whoa!  Hold on a second!  

Just because the subject came up doesn't mean we need to expand the current
discussion to include the design of `if-implements'.  We're talking about
whether the Scheme RFC editors are going to be in the business of passing
judgements about the implementability of proposals, or whether their role
will be confined to keeping the documents readable and relevant.  I think
we can decide that issue without delving into the design of
`if-implements'.

I have things to say about your proposal, but I only have so much time and
energy to devote to this stuff, so I'd prefer not to get into it until
necessary.

In response to Matthias's concern about being able to tell the
implementable RFCs apart from the informational RFCs, let me suggest that
we add a "Category" field to each Scheme RFC -- possible values for the
category might include INFORMATIONAL, OPINION, API, etc. (but let's not get
bogged down in designing the set of categories right now).  An author who's
hoping someone will actually implement her proposal would choose a category
like API.  The editors and reviewers [*] would make sure the category
actually described the contents of the document, and in the case of a
proposed API, they would put some effort into ensuring that the API was
implementable.

I suppose that some of you might be worried that the author and the
reviewers will get into big arguments about whether it is possible to
implement some APIs.  But consider: authors and reviewers are on the -same-
-side- when it comes to ensuring implementability.  If a reviewer spots a
problem, the author will want to fix it.  If a reviewer can't figure out
how to implement some particularly tricky feature, the author will -want-
to explain how to do it, and will be happy to include this information in
her RFC in order to help others implement her API.  Heck, authors will
often provide reference implementations without prompting.  This isn't a
contest where authors get points for fooling the editor and reviewers into
publishing an unimplementable API!

And if there is some ultimate disagreement about implementability between
author and reviewers that can't be resolved, then everyone should just work
on making it as readable as possible before publishing it (as an API if the
author still insists).  If it can't be implemented, it won't be.

[*] One thing I really -like- about the proposed mechanism is the automatic
formation of a mailing list to conduct a review of any proposed Scheme RFC.