new-extension-process

Scheme extension report process

Motivation

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:

• Community participation in finalization, through voting, means that accepted extensions carry greater force and support. Voting is anonymous to allow votes without retribution.
• Implementors will reject implementing inconsistent proposals within their systems, as they typically strive for consistency in their libraries.
• Requiring some degree of actual implementation in major Scheme systems will ensure that finalized extensions are not only accepted on paper, but are available to programmers in practice.

Process

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:

• While proposals may be discussed for an indefinite amount of time in the current process, it may be worthwhile to consider some fixed time limit after which dormant proposals are automatically put into the withdrawn status.
• Conversely, some reasonable minimum discussion time should prevent rushed proposals. Perhaps one month.
• Voting is to be anonymous, verifiable, and fair. See below for a possible voting protocol.
• When a person votes for a proposal, he may specify that he is an implementor or a user of a Scheme system that he attests to the support of that Scheme system for the proposal. This provides the basis on which the necessary support for finalization is determined. The mechanism may be stronger for some proposals, such as those with specifications that can be tested with simple test suites.
• Any voter who attests to a particular Scheme system's support for a proposal may attest to only one Scheme system and as either an implementor or a user; he may not attest as both. Therefore, if N is 3, at least six votes are necessary to finalize a proposal.
• It is unspecified how support for the proposal is determined as required by the voting process. Some proposals should have test suites, whereas others may need more careful examination by either the author of the proposal or the maintainers.
• The author of a proposal may not vote on the proposal, though the maintainers may.
• The number of Scheme systems (N) that of each at least one implementor and user must affirm a proposal for should be adjusted. Three sounds like a good number, but this should be discussed.
• Similarly, the number of Scheme systems (M) required for the final and widely supported status should be decided. Six or seven sounds like a good number.
• The structure of proposals is pretty much the same as SRFI documents, except that the reference implementation should include a test suite, and the format of the main document will be something better than HTML 3.2. (Draft proposals may be in plain text; final reports will be in some convenient interchange format, possibly Texinfo with a few useful macros for the structure.)

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.

category-standards