Changes between Version 1 and Version 2 of Process


Ignore:
Timestamp:
Nov 24, 2009 1:48:09 PM (6 years ago)
Author:
simonmar@…
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Process

    v1 v2  
    2727== Overview ==
    2828
    29 In concrete terms, here's the overview of the new process.
    30 
    31  * '''Modularise''': proposals are developed independently, from
    32    idea to complete addendum (almost a patch to the Report).  Each
    33    proposal is driven by a person or small group, not necessarily just
    34    committee members.  The owner(s) of the proposal will be given
    35    access to modify the wiki.  Ideally a proposal should be implemented in a compiler with a flag
    36    to turn it on and off, so people can experiment with it.  In this
    37    sense, a proposal corresponds to a language "extension", although
    38    the proposal may not necessarily extend the language.
     29 * '''Proposals''': each proposal describes a single change to the language.
     30   Proposals start life as a discussion on the mailing list, and end up
     31   as a complete description of the proposed changes to the language spec,
     32   at which point the proposal is a candidate for inclusion in the next
     33   revision.  More details in the [#Proposals Proposals] section below.
    3934
    4035 * '''Regular release cycles''': at regular intervals (currently 12 months),
    4136   a new revision of the language standard will be released, by
    4237   integrating some of the mature proposals into the previous
    43    revision.
     38   revision.  Each revision is announced around October-November.
    4439
    45  * There is a committee, collectively responsible for choosing which
    46    proposals to integrate.  The committee has a chair and co-chair,
     40 * There is a [wiki:Committee committee], collectively responsible for choosing which
     41   proposals to integrate.  The committee has a chair (and possibly co-chair),
    4742   who are responsible for editing and producing the new language
    4843   definition.  Every release cycle, the the chair, co-chair, and some
    49    of the committee are replaced.
     44   of the committee are replaced.  The decision period during which
     45   the committee discusses which proposals to incorporate is short,
     46   and is essentially just a yes/no for each complete proposal.
    5047
    5148Each cycle can tune the number of proposals it accepts so that it can
     
    5855drastically reduces the chances that errors will creep in.
    5956
    60 == The lifecycle of a proposal ==
     57== Proposals ==
     58
     59The following describes the lifecycle of a proposal.
    6160
    6261Here's the lifecycle of a proposal, fleshing out a bit more what
     
    6463
    6564 * A proposal starts on the [http://haskell.org/mailman/listinfo/haskell-prime haskell-prime mailing list], with discussion amongst the
    66    community.
     65   community.  Anyone can start a discussion about a proposed change to the language: just post to the list.
    6766
    68  * If after some discussion the proposal seems plausible, it is turned
    69    into a formal proposal and moved to the wiki (see ProposalTemplate).  Each proposal has a
    70    name (e.g. `RankNTypes`), which should be used as a subject line prefix
    71    on the mailing list when discussing it.
     67 * Ideally the language change should be implemented already, so that experience gained with the implementation can inform the discussion.
    7268
    73  * The community discuss the proposal.  Each proposal has an owner or
    74    owners who are responsible for refining the proposal.  In order to
    75    be accepted, a proposal should precisely specify the language
    76    extension: its syntax, semantics (informally, as in the current
    77    Report), and interactions with other language features.
     69 * If after some discussion the proposal seems plausible, someone should volunteer to be
     70   the proposal owner.  A committee member will give the owner access to the wiki and
     71   ticket system.  The owner should
     72   * Decide on a name for the proposal, if it doesn't already have one.  Names are in !CamelCase, e.g. `RankNTypes`.   
     73     The name should be used as a subject line prefix for mailing list discussion.
     74   * create a ticket for the proposal
     75   * create a wiki page using ProposalTemplate
    7876
    79  * When broad consensus has been reached, the owner(s) document the changes and additions
    80    to the Report necessary to implement the proposal (an "addendum").  Having done this,
    81    the proposal can be marked "complete", and is a candidate for selection
    82    at the next language revision.
     77 * 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
    8378
    84  * The committee discusses which proposals will go in the next release.
    85    The committee chair and co-chair are then responsible for aggregating
    86    the final addenda into a revision of the Report.
     79 * 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
     80   is complete, the ticket can be moved into the "complete" state, and the proposal is a candidate for acceptance in the next revision.
     81
     82 * 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.
    8783
    8884== Timeline ==
    8985
    9086 * Throughout the year: discuss and refine proposals
    91  * Review period (August/September): committee chooses which addenda to include
    92  * Haskell Symposium: Announcement of accepted proposals
    93  * Following the announcement, the report will be edited to incorporate the changes, and then published.
    94  
     87 * Review period (a 2-week period around September-October): committee chooses which addenda to include
     88 * Following the review period:
     89   * Announcement of accepted proposals
     90   * Form a new [wiki: Committee committee]
     91 * The committee chair/co-chair produce a revision of the language standard by incorporating the accepted proposals
     92
    9593== Major revisions ==
    9694
     
    104102
    105103We expect releases to be made late in the year, around
    106 September-October.  Hence, each release will be named after the year
     104October-November.  Hence, each release will be named after the year
    107105following the year of release.  For example, the language revision
    108 released in October 2009 will be named "Haskell 2010".
     106released in November 2009 will be named "Haskell 2010".
    109107
    110108== Compiler support ==