Changes between Version 1 and Version 2 of Process


Ignore:
Timestamp:
Nov 24, 2009 1:48:09 PM (4 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 ==