There are many other things that this process is not. Discussion of those, rationales for some of the implementation details, and answers to related questions are to be found in the SRFI FAQ page.
Related to this process is a Scheme special form, documented in SRFI 7, that a Scheme program can use to ascertain whether an implementation supports a particular standard or feature.
http://srfi.schemers.org/will provide an archive of draft, final and withdrawn SRFIs and a submission process to submit SRFIs for consideration.
The editors of the SRFIs will be experienced members of the Scheme community independent of the major implementors. They will attempt to keep the quality of SRFIs high, but will ultimately accept any SRFI which conforms to the structure requirements below.
A moderated mailing list,
srfi-announce at srfi dot schemers dot org,
will be used to announce when new SRFI proposals become drafts.
It will carry a final notification when
the SRFI has been either final or withdrawn.
Anyone can subscribe to the list, and implementors are
especially encouraged to subscribe.
There will be a mailing list created for the evaluation period of each SRFI where all discussion of the proposal will take place. Anyone may join these lists. The discussion will be archived and the archived discussion will remain part of the permanent record of the SRFI.
srfi minus editors at srfi dot schemers dot org.
srfi minus announce at srfi dot schemers dot org. As part of the initial editing process, the editors will ensure that related standards (RnRS, SRFIs, RFCs and others) are appropriately identified and that the proposal meets the structural requirements described below. If other related standards are identified during the comment process or after acceptance, the editors will keep the references up-to-date. A proposal cannot normally be finalized until 60 days have passed since its initial submission.
This part of the process is being reconsidered:
The total discussion period must not exceed 90 days. Active discussion or revision after 90 days normally suggests that a proposal has been revised at least three times and is not yet mature enough for standardization.
srfi minus announce at srfi dot schemers dot org.
Once the SRFI number has been assigned, the proposal will be in one of three states: draft, final, or withdrawn. Lists of proposals in all three states will be available and archived indefinitely, and SRFI numbers will not be reused. The only changes that may be made to a final SRFI are:
Every Scheme implementation is encouraged to provide implementations of final SRFIs where possible, and to retain existing implementations of deprecated SRFIs for a reasonable time period.
New standards, such as RnRS, may supersede or conflict with existing
SRFIs. The editors and authors will work to update the relationship
of active SRFIs to such standards.
Every SRFI must meet the following requirements:
The sample implementation should normally conform to the specification in point 6 above. If there is any variance (such as the implementation being overly restrictive), the specification will be considered correct, the variance should be explained, and a timetable provided for the sample implementation to meet the specification.
The sample implementation should include automated tests. Tests make porting to new Scheme implementations easier. They also help users understand how your SRFI is to be used. However, if the sample implementation is trivial or not really meant to be used, i.e. it is just a proof of concept, it's okay to omit tests. That should be a rare case. No specific test framework is required, but both SRFI 64 and SRFI 78 are available.
A SRFI may be submitted without an implementation so that the specification may be refined before effort is invested in implementing it. However, an implementation should be provided as soon as possible.
Copyright (C) AUTHOR (YEAR).
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
In particular, lack of a sample implementation (as defined above) is grounds for rejection. This can only occur if the "sample implementation" requirement is being met by an outlined implementation (type 5), and there is consensus that the implementation outline is not adequate. Note that this is never a permanent rejection, because creation of an implementation of one of the other types is a complete refutation of this basis for rejection.
The other likely basis for rejection is an inadequate design specification. In this case, the editors will attempt to help the author(s) conform to the requirements.
Remember, even if a proposal becomes a final SRFI, the need for it must be
compelling enough for implementors to decide to incorporate it into
their systems, or it will have been a waste of time and effort for
everyone involved. If the quality of any SRFI is not high, the
likelihood of implementors adding this feature to their implementation
is extremely low.
The following terms may be used in SRFIs with the corresponding definitions:
The term "a SRFI <n>-conformant implementation" means an
implementation of Scheme which conforms to the specification described
in SRFI <n>.
The history of this document is here.