Skip to content

Changes

Page history
Edit Process authored by simonmar@microsoft.com's avatar simonmar@microsoft.com
Hide whitespace changes
Inline Side-by-side
process.md
View page @ 758a25d3
......@@ -35,29 +35,24 @@ development of the Haskell language.
## Overview
In concrete terms, here's the overview of the new process.
- **Modularise**: proposals are developed independently, from
idea to complete addendum (almost a patch to the Report). Each
proposal is driven by a person or small group, not necessarily just
committee members. The owner(s) of the proposal will be given
access to modify the wiki. Ideally a proposal should be implemented in a compiler with a flag
to turn it on and off, so people can experiment with it. In this
sense, a proposal corresponds to a language "extension", although
the proposal may not necessarily extend the language.
- **Proposals**: each proposal describes a single change to the language.
Proposals start life as a discussion on the mailing list, and end up
as a complete description of the proposed changes to the language spec,
at which point the proposal is a candidate for inclusion in the next
revision. More details in the [Proposals](process#proposals) section below.
- **Regular release cycles**: at regular intervals (currently 12 months),
a new revision of the language standard will be released, by
integrating some of the mature proposals into the previous
revision.
revision. Each revision is announced around October-November.
- There is a committee, collectively responsible for choosing which
proposals to integrate. The committee has a chair and co-chair,
- There is a [committee](committee), collectively responsible for choosing which
proposals to integrate. The committee has a chair (and possibly co-chair),
who are responsible for editing and producing the new language
definition. Every release cycle, the the chair, co-chair, and some
of the committee are replaced.
of the committee are replaced. The decision period during which
the committee discusses which proposals to incorporate is short,
and is essentially just a yes/no for each complete proposal.
Each cycle can tune the number of proposals it accepts so that it can
......@@ -70,7 +65,11 @@ have to worry about. Keeping the interactions to a manageable level
drastically reduces the chances that errors will creep in.
## The lifecycle of a proposal
## Proposals
The following describes the lifecycle of a proposal.
......@@ -79,39 +78,36 @@ happens in the release cycle:
- A proposal starts on the [ haskell-prime mailing list](http://haskell.org/mailman/listinfo/haskell-prime), with discussion amongst the
community.
community. Anyone can start a discussion about a proposed change to the language: just post to the list.
- If after some discussion the proposal seems plausible, it is turned
into a formal proposal and moved to the wiki (see [ProposalTemplate](proposal-template)). Each proposal has a
name (e.g. `RankNTypes`), which should be used as a subject line prefix
on the mailing list when discussing it.
- Ideally the language change should be implemented already, so that experience gained with the implementation can inform the discussion.
- The community discuss the proposal. Each proposal has an owner or
owners who are responsible for refining the proposal. In order to
be accepted, a proposal should precisely specify the language
extension: its syntax, semantics (informally, as in the current
Report), and interactions with other language features.
- If after some discussion the proposal seems plausible, someone should volunteer to be
the proposal owner. A committee member will give the owner access to the wiki and
ticket system. The owner should
- When broad consensus has been reached, the owner(s) document the changes and additions
to the Report necessary to implement the proposal (an "addendum"). Having done this,
the proposal can be marked "complete", and is a candidate for selection
at the next language revision.
- Decide on a name for the proposal, if it doesn't already have one. Names are in CamelCase, e.g. `RankNTypes`.
The name should be used as a subject line prefix for mailing list discussion.
- create a ticket for the proposal
- create a wiki page using [ProposalTemplate](proposal-template)
- The committee discusses which proposals will go in the next release.
The committee chair and co-chair are then responsible for aggregating
the final addenda into a revision of the Report.
- Discussion continues, with the wiki page being gradually refined into a precise description of the proposal, and including rationale (points both for and against) arising during the discussion
## Timeline
- The aim is to add to the proposal a "Report Delta", which is a list of changes to the report necessary to implement the change. When the report delta
is complete, the ticket can be moved into the "complete" state, and the proposal is a candidate for acceptance in the next revision.
- The committee discusses which proposals will go in the next revision. Following the discussion, the tickets are updated to reflect which proposals were accepted. Wiki pages for proposals will be updated with a summary of the points raised during this discussion. Proposals that were not accepted may be refined further and reconsidered in the next cycle.
- Throughout the year: discuss and refine proposals
- Review period (August/September?): committee chooses which addenda to include
- Haskell Symposium: Announcement of accepted proposals
- Following the announcement, the report will be edited to incorporate the changes, and then published.
## Timeline
- Throughout the year: discuss and refine proposals
- Review period (a 2-week period around September-October): committee chooses which addenda to include
- Following the review period:
- Announcement of accepted proposals
- Form a new [Committee committee](wiki-start)
- The committee chair/co-chair produce a revision of the language standard by incorporating the accepted proposals
## Major revisions
......@@ -129,9 +125,9 @@ needed for textbooks, for example.
We expect releases to be made late in the year, around
September-October. Hence, each release will be named after the year
October-November. Hence, each release will be named after the year
following the year of release. For example, the language revision
released in October 2009 will be named "Haskell 2010".
released in November 2009 will be named "Haskell 2010".
## Compiler support
......