Scheme extension report process


The SRFI process served the Scheme community well for its first four years. It provided a motivation for Schemers to coordinate their efforts creating Scheme extensions within an implementation neutral context, and the most of the resulting specifications found implementations across the range of major Scheme systems.

Within the last two years, weaknesses in the process have become apparent which this process seeks to address.

SRFI discussions can sometimes become dominated by three or four very vocal individuals, and reach a tone which intimidates participation from others.

The SRFI process leaves the decision of finalization ultimately within the hands of the SRFI author. SRFIs can then be finalized, giving them a perceived legitimacy that stems from the early success of the process which may be undeserved. The SRFI may be inconsistent with earlier SRFIs and current Scheme practices.

Then, a finalized SRFI says nothing about its availability in actual Scheme implementations. Weak SRFIs may never or rarely be implemented in major Scheme implementations, leading to a dilution of the force, perceived or real, of the SRFI process itself.

The <NAME HERE> process seeks to address these weaknesses with a some new approaches, while preserving much of what was right with the SRFI process. This process ties actual widespread implementation with finalization, and invites community participation through voting to ensure real support. Doing so encourages consistency and usability in a number of ways:


  1. An author will submit a proposal to the maintainers via electronic mail or a web form.
  2. A maintainer will respond to a proposal either by noting that it does not satisfy the conditions of an initial proposal or by making the proposal document publicly available on the web and setting up a mailing list for the discussion of the proposal.
  3. The proposal is initially in draft status. It will be discussed on the mailing list indefinitely in this status. During this time, the author may update the document to reflect amendments to the proposal or errors in the proposal document's text.
  4. After an arbitrary amount of time no shorter than a specified minimum, usually after some sort of consensus has been reached, the author of the proposal may choose one of two options: withdraw the proposal or initiate a vote to finalize the proposal.
  5. If the proposal is withdrawn by the author, it is put into withdrawn status, and the process is terminated at this point. Note that withdrawn proposals may later be revived; see below on reviving withdrawn proposals.
  6. Otherwise, a vote is taken. Anyone may vote either in favour of the proposal, against the proposal, or to abstain. The voting period is fixed within a certain time limit, and during the voting period no amendments may be made to the proposal or modifications made to the document.
  7. If there is a majority against the proposal, it is put into the withdrawn status, and the process is terminated. It may later be revived, however; see below on reviving withdrawn proposals.
  8. If there was no majority either in favour or opposed to the proposal, it remains in draft status and discussion will continue indefinitely as if from step 3.
  9. Two conditions must be met for a proposal to be finalized: one, a majority must have voted in favour of it; and two, there must be at least N Scheme systems that support the proposal such that an implementor and a user of each Scheme system voted in favour of the proposal and attest to the support of that Scheme system for the proposal. If neither of these conditions is met, discussion will proceed as from step 3.
  10. If a vote is successfully made to finalize a proposal, it is put into final status, the mailing list archive & proposal document are frozen, the proposal becomes a report, and a post-finalization discussion mailing list is set up. The final report may not be modified except to correct small mistakes in the text that the author, maintainers, and at least one other party all agree to.
  11. After the proposal has become a final report, if M Scheme systems can claim support for it, the report goes into the final and widely supported status.
  12. If a new proposal is finalized that is determined to make an older final report obsolete, the older report is put into the obsolete status.

Notes on the process:

A possible voting protocol:

A centralized website run by the maintainers accepts registrations.

  1. A user registers, providing a full name, e-mail address.
  2. When a vote is called, the user logs in, and selects the proposal being voted on, and may claims his or her status as an implementor or as a user vouching for a specific implementation.
  3. The system provides a random PIN as a voting token (possibly as an WikiPedia:CAPTCHA to prevent automated cheating), and associates the random number with the vote and the status (but not the user's details).
  4. The user then enters the PIN, and selects their vote, For, Against, or Abstain.
  5. When the voting period ends, the system sends an email to the discussion list, listing the Names and Emails of voters, and identifies the implementors (but not verifiers), then in a separate section lists the PINs in numeric order, and the votes, For, Against, or Abstain. In a final section the number of For votes, Against votes, Abstentions, and Implementation Vouchers are displayed.

The proposal above protects the voters from retribution by keeping their actual votes anonymous. The display of the PINs allows individual voters to verify the accurate recording of their individual votes, and allows the group to see that the voting requirements for finalization are or are not met.