This page describes a possible process for managingSML Basis Library proposals.Please useissue 11 to discuss theproposed process.

This document describes the process whereby a proposal for a modification or additionto the Basis Library becomes blessed as part of the standard. This process is partiallymodeled after theScheme RFI process, butmodified to better serve the SML Basis Library. In particular, additions to the BasisLibrary are expected to be supported by all SML implementations (unless they are optional),and therefore, the bar for standardization should be higher than in the SRFI process.

The process attempts to meet the following three goals:

1. Support from implementations. If SML implementations do not support the processby agreeing to implement proposed library additions, then we lose the benefits ofstandardization.

2. The process should be expeditious, but thorough. We want new features to make theirway into implementations in a timely fashion, but we want to avoid prematurely standardizinga feature and we want to avoid churn the programming environment.

3. The process of debating, evaluating, and approving proposals should be transparent.The discussion of a proposal should be open to all members of the SML community.

The major parts of the process are detailed below. They include the process for handlinga proposal, editors who manage the process, and a steering committee that appoints theeditors and approves changes to the specification.

A proposal will go through the following steps:

1. the proposal writeup including reference implementation and test cases willbe submitted to the editors. Each proposal will be assigned amanagingeditor who will oversee the process for that proposal.

2. The managing editor and proposer(s) will make any necessary changes to bring theproposal in line with theGuidelines.

3. Once the proposal meets theGuidelines,it will haveDRAFT status and the following steps will be executed:

   • the proposal will be assigned a number of the formYYYY-DDD, whereYYYY is thecurrent year andDDD is the number of the proposal for the year.
   • the proposal write up will be posted to theGitHub wiki.
   • the sample and test code will be posted to the GitHub repository in thedirectoryCode/YYYY/DDD.
   • An associated GitHub issue will be created for tracking the discussion aboutthe proposal.

4. There will be a discussion period of 90 days from the time when the proposalis posted. During that period, the proposer may make changes to the proposalin response to the discussion. If the changes are significant, the discussionclock will be reset. The need to reset the clock is determined by the managingeditor. During this period, the proposer may also choose to withdraw theproposal, in which case its status changes toWITHDRAWN.

5. When the discussion period is complete, the proposal's status will change toPENDING.The purpose of the pending period is to give SML implementors a chance toupdate their systems and for SML users to experiment with the features.It is an opportunity to catch any significant mistakes before promoting aproposal to be part of the official Basis Library specification.

6. Once a proposal isPENDING it may be voted on by the steering committeeat any time. If approved by a majority vote, the proposal becomes part of thenext release of the SML Basis Library specification. If a proposal is notapproved, then the Steering Committee may either vote toREJECT it, leaveit asPENDING to allow further evaluation, or recommend that it be withdrawnand revised. Proposals that have been rejected should not be resubmitted.

7. Rather than release each proposal as it is approved, there will be annual updatesto the Basis Library Specification that will include those proposals that have beenapproved in the previous year.

The SML Basis Library will be maintained by an editorial board of two to threeeditors. These editors will be responsible for managing the process described aboveand for maintaining the online documentation of approved and pending proposals.Editors should not be in charge of managing their own proposals (or proposalstied to their own implementation).

The editors should be drawn from the SML implementors community and should come fromdifferent implementations. The term of an editor is three years (although these shouldbe staggered to avoid wholesale turnover of the board every three years). When aneditor's term has expired, he or she will continue to manage the proposals for which he or sheis the managing editor.

The purpose of the steering committee is to pick the editors and to approve proposals forinclusion in the SML Basis Library specification. The committee will include representativesfrom the actively maintained implementations of Standard ML. Currently, these implementationsinclude the following:

• HaMLet

• ML Kit Compiler

• MLton

• Moscow ML

• PolyML

• Standard ML of New Jersey

In addition, the committee will include two outside members from the user community.