Process

Process for submitting proposals [ DRAFT PROPOSAL ]

This page describes a possible process for managing SML Basis Library proposals. Please use issue 11 to discuss the proposed process.

Introduction

This document describes the process whereby a proposal for a modification or addition to the Basis Library becomes blessed as part of the standard. This process is partially modeled after the Scheme RFI process, but modified to better serve the SML Basis Library. In particular, additions to the Basis Library 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 process by agreeing to implement proposed library additions, then we lose the benefits of standardization.

2. The process should be expeditious, but thorough. We want new features to make their way into implementations in a timely fashion, but we want to avoid prematurely standardizing a 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 handling a proposal, editors who manage the process, and a steering committee that appoints the editors and approves changes to the specification.

Process

A proposal will go through the following steps:

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

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

3. Once the proposal meets the Guidelines, it will have DRAFT status and the following steps will be executed:

   • the proposal will be assigned a number of the form YYYY-DDD, where YYYY is the current year and DDD is the number of the proposal for the year.
   • the proposal write up will be posted to the GitHub wiki.
   • the sample and test code will be posted to the GitHub repository in the directory Code/YYYY/DDD.
   • An associated GitHub issue will be created for tracking the discussion about the proposal.

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

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

6. Once a proposal is PENDING it may be voted on by the steering committee at any time. If approved by a majority vote, the proposal becomes part of the next release of the SML Basis Library specification. If a proposal is not approved, then the Steering Committee may either vote to REJECT it, leave it as PENDING to allow further evaluation, or recommend that it be withdrawn and revised. Proposals that have been rejected should not be resubmitted.

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

Editors

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

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

Steering committee

The purpose of the steering committee is to pick the editors and to approve proposals for inclusion in the SML Basis Library specification. The committee will include representatives from the actively maintained implementations of Standard ML. Currently, these implementations include 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.