process.md

+# The Haskell Prime Process
+
+## Background
+
+
+The effort to define a new version of the Haskell language,
+Haskell-prime, was started in 2005.  Since then we have made plenty of
+progress in exploring the design space, but relatively little progress
+towards a concrete revision of the language specification.
+
+
+Around ICFP'08 there was some discussion amongst the committee as to
+the best way to proceed.  The basic problem we identified is that the
+existing process was too monolithic.  We had already decided to
+separate Haskell-prime into two stages, alpha and beta, so that we
+could defer the difficult topic of Functional Dependencies and Type
+Families until later, but even getting to the alpha stage was still a
+mammoth task and it was not clear that it would be done in a
+reasonable amount of time, if at all.
+
+
+The committee discussed how we might make the process more
+incrememtal, so that it can be a sustainable, ongoing process that
+lasts beyond the current committee and beyond just one revision of the
+language.  Many of us are familiar with these kind of ongoing
+incremental processes from open source software development, where it
+works well, so we plan to adopt aspects of these processes in the
+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.
+
+- **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.
+
+- There is a committee, collectively responsible for choosing which
+  proposals to integrate.  The committee has a chair and 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.
+
+
+Each cycle can tune the number of proposals it accepts so that it can
+be sure to complete on time.  Proposals can continue along their
+development process independently of the language revision cycle, thus
+the only bottleneck in the process is the number of proposals that can
+be accepted in a given revision, but keeping this number low is a good
+thing: the lower the number of additions, the fewer interactions we
+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
+
+
+Here's the lifecycle of a proposal, fleshing out a bit more what
+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.
+
+- 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.
+
+- 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.
+
+- 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.
+
+- 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.
+
+## Timeline
+
+- 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.
+
+## Major revisions
+
+
+From time to time, when it is deemed appropriate, the committee may
+designate a release of the language a "major revision".  It is
+expected that major revisions of the language will be supported for
+longer than the yearly releases, and provide the stable baseline
+needed for textbooks, for example.
+
+## Naming
+
+
+We expect releases to be made late in the year, around
+September-October.  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".
+
+## Compiler support
+
+
+We expect that GHC will support a number of previous revisions to the
+language, with a flag such as `-language-revision=2010`.  Individual
+extensions can be enabled and disabled separately as usual.
+
+
+Other compilers can choose which revision(s) of the language are
+supported, though it is expected that most compilers will support at
+least the most recent major revision.