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
@@ -19,6 +22,7 @@ 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
@@ -27,26 +31,33 @@ 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
 
-- **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.
+
+
+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.  Each revision is announced around October-November.
+  revision.
 
-- There is a [committee](committee), collectively responsible for choosing which
-  proposals to integrate.  The committee has a chair (and possibly co-chair),
+- 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.  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.
+  of the committee are replaced.
 
 
 Each cycle can tune the number of proposals it accepts so that it can
@@ -58,68 +69,83 @@ 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.
 
-## Proposals
 
+## The lifecycle of a proposal
 
-The following describes 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.  Anyone can start a discussion about a proposed change to the language: just post to the list.
-
-- Ideally the language change should be implemented already, so that experience gained with the implementation can inform the discussion.
 
-- 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
+- A proposal starts on the [ haskell-prime mailing list](http://haskell.org/mailman/listinfo/haskell-prime), with discussion amongst the
+  community.
 
-  - 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)
+- 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.
 
-- 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
+- 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.
 
-- 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.
+- 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 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.
+- 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
-- The committee will meet in February, May, August and November. They will review proposals completed before that month, and make a decision about which to accept
-- After the committee has met, the decisions will be announced on the mailing list
-- In January of the following year, the committee chair will produce a revision of the language standard by incorporating the accepted proposals
-- A new [committee](committee) will then be formed
+- 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 early in the year, normally during January.
-Each release will be named after the year of the release.
-For example, the language revision released in January 2014 will be named "Haskell 2014".
+
+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.
+
+