Add committee bylaws

README.rst

@@ -4,7 +4,7 @@ GHC Proposals
 This repository contains specifications for proposed changes to the
 `Glasgow Haskell Compiler <https://www.haskell.org/ghc>`_.
 The purpose of the GHC proposal process and of
-the GHC Steering Committee, is to broaden the discussion of the evolution of
+the GHC Steering Committee is to broaden the discussion of the evolution of
 GHC.
 
 * `≡ List of proposals under discussion <https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Aopen+is%3Apr+no%3Alabel>`_
@@ -14,7 +14,7 @@ GHC.
 * `≡ List of rejected proposals <https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Apr+label%3A%22Rejected%22>`_
 * `≡ List of implemented proposals <https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Apr+label%3A%22Implemented%22>`_
 * `≡ List of all proposals <https://github.com/ghc-proposals/ghc-proposals/pulls?q=>`_
-
+  
 What is a proposal?
 -------------------
 
@@ -250,7 +250,8 @@ Alejandro Serrano       `@serras <https://github.com/serras/>`_               20
 Arnaud Spiwack          `@aspiwack <https://github.com/aspiwack/>`_           2019/07
 ======================  ====================================================  =======  =========
 
-The committee members have committed to adhere to the `Haskell committee guidelines for respectful communication <GRC.rst>`_.
+The committee members have committed to adhere to the `Haskell committee guidelines for respectful communication <GRC.rst>`_ and are subject to the
+`committee bylaws <https://github.com/ghc-proposals/ghc-proposals/blob/master/committee.rst>`_.
 
 We would also like to thank our former members:
 
@@ -264,8 +265,8 @@ Christopher Allen       `@bitemyapp <https://github.com/bitemyapp>`_          20
 ======================  ====================================================  =================
 
 
-Committee process
------------------
+Committee process for responding to a proposal
+----------------------------------------------
 
 The committee process starts once the secretary has been notified that a
 proposal is ready for decision.
@@ -395,33 +396,9 @@ is a polite ping/enquiry.
       proposal with the implementation status (i.e. ticket URL and the
       first version of GHC implementing it.)
 
-      Concretely, a committee member must perform the following steps:
-
-      1. Add a new commit on top of the PR branch that:
-
-         a. Changes the filename of the proposal to correspond to the PR number.
-
-         b. Updates any metadata fields that may have changed in the template on ``master`` since
-            the PR branch split off.
-
-         c. Fills in these metadata fields as appropriate, including changing "is discussed"
-            to "was discussed".
-
-      2. Merge the PR branch into master, and push.
-
-      3. Update the PR description to start
-         with the text "The proposal has been accepted; the following discussion is mostly of historic interest."
-         where the word "proposal" links to the final rendered version pushed above.
-
-      4. If the PR title has "(under review)", remove it.
-
-      5. Set the PR to have the "Accepted" label.
-
-      6. Comment on the PR that the proposal was accepted.
-
-      7. Close the PR if GitHub has not detected the merge.
-
-      8. Announce on the committee mailing list.
+      Committee members should see the `acceptance page <https://github.com/ghc-proposals/ghc-proposals/blob/master/acceptance.rst>`_ for a checklist
+      to be applied to accepted proposals and the steps necessary in
+      order to mark a proposal as accepted.
 
 Review criteria
 ---------------

acceptance.rst

@@ -0,0 +1,63 @@
+How to Accept a Proposal
+========================
+
+This document describes the technical process for accepting a proposal,
+assuming the proposal has gone through the `proposal process <https://github.com/ghc-proposals/ghc-proposals/#committee-process>`_.
+
+Acceptance checklist
+--------------------
+
+Before accepting, the shepherd should check for the following
+(extracted from the `review criteria <https://github.com/ghc-proposals/ghc-proposals/#review-criteria>`_):
+
+1. Is the proposal self-standing? It should not refer explicitly to the GitHub
+   trail, for instance.
+
+2. Is the proposal precise? The specification section should fully describe
+   the proposal payload. In particular:
+
+   a. If there is new syntax, is it described in BNF notation?
+
+   b. If applicable, are there typing rules? If there are not, could
+      typing rules be reasonably extracted from the proposal text?
+
+   c. Are any changes to runtime behavior precisely specified?
+
+   d. Is there a reasonable description of how the new feature might
+      be documented in Haddock? Linted by HLint? Treated by other tools?
+      (These will not apply to every proposal.)
+
+3. Is the proposal sufficiently illustrated with examples? Examples help
+   us understand the details that will be needed during implementation.
+
+Acceptance steps
+----------------
+
+A committee member accepts a proposal by following this sequence of
+steps:
+
+1. Add a new commit on top of the PR branch that:
+
+   a. Changes the filename of the proposal to correspond to the PR number.
+
+   b. Updates any metadata fields that may have changed in the template on ``master`` since
+      the PR branch split off.
+
+   c. Fills in these metadata fields as appropriate, including changing "is discussed"
+      to "was discussed".
+
+2. Merge the PR branch into master, and push.
+
+3. Update the PR description to start
+   with the text "The proposal has been accepted; the following discussion is mostly of historic interest."
+   where the word "proposal" links to the final rendered version, as found on https://github.com/ghc-proposals/ghc-proposals/tree/master/proposals
+
+4. If the PR title has "(under review)", remove it.
+
+5. Set the PR to have the "Accepted" label.
+
+6. Comment on the PR that the proposal was accepted.
+
+7. Close the PR if GitHub has not detected the merge.
+
+8. Announce on the committee mailing list.

committee.rst

@@ -0,0 +1,168 @@
+GHC Steering Committee Bylaws
+=============================
+
+This document describes the GHC Steering Committee and the
+bylaws by which it operates.
+
+* `Current committee membership <https://github.com/ghc-proposals/ghc-proposals/#who-is-the-committee>`_
+
+Committee Composition
+---------------------
+
+The committee is formed of roughly 10 members of the Haskell community
+who wish to volunteer for this service. It is our aim that this committee
+be diverse; by representing different viewpoints, we will make decisions
+that benefit larger segments of our community.
+
+Specifically, we would like the committee to represent at least the following
+constituencies:
+
+* GHC developers
+* Authors (whether in print or online)
+* Educators
+* Industrial users
+* Researchers
+* Tooling developers
+
+We recognize that we may not always live up to this ideal, but when
+choosing new members, we aim to correct any imbalances.
+
+Committee Roles
+---------------
+
+* **Co-chairs.** The committee has two co-chairs. This role is more ceremonial
+  than practical, as all members of the committee have the right
+  to set the agenda and move our business forward. The co-chairs
+  are the stop of last resort for any issues of contention, but are
+  not otherwise distinguished from other members of the committee.
+
+  Agreement among the co-chairs can initiate a process to remove a member from
+  the committee. If this happens, the co-chairs must explain their rationale
+  to the entire committee, including the member that has been removed. In
+  order to avoid public embarrassment, it is expected that this communication
+  be by private email, not via a mailing list of public record. (The chairs
+  may choose, however, to use public channels, in egregious circumstances.)
+  The committee does not need to weigh in during this process, though the
+  expectation is that if the co-chairs abuse their power, the committee will
+  vote them out of their chairships.
+
+* **Secretary.** The committee has one secretary. The secretary is the first stop for keeping
+  our repository up-to-date and running our selection process.
+
+* **Nudger.** The committee has one nudger. The nudger's job is to make sure other
+  committee members are fulfilling their duties by nudging them (often
+  in public) to do so.
+
+The co-chairs and secretary
+positions remain with an individual until they decide to relinquish the
+role, though a majority vote among the committee can strip a member of
+their co-chair/secretary position.
+
+The nudger position rotates among members every six months.
+In the event that the nudger ends up needing nudging (by any other member
+of the committee), the nudger should step down and volunteer to do a better
+job in some future six months; in the event that they still struggle to
+stay on top of their nudging duties, it may be a sign that they are too
+busy for committee work and should step down.
+
+The secretary is in charge of managing who the nudger is, by creating
+a rotation for this position.
+
+Guidelines for Communication
+----------------------------
+
+All members of the Steering Committee agree to abide by the
+`Guidelines for Respectful Communication <https://github.com/ghc-proposals/ghc-proposals/blob/master/GRC.rst>`_. As the guidelines document
+describes, if one of us errs in our communication, please
+opt to bring up the matter with that individual directly.
+If that is not feasible, then please bring it up with the
+(co-)chair of the committee. Everyone should feel welcomed
+to contribute to the growth of GHC and Haskell, and we eagerly
+want to know when our actions cause someone not to feel that
+way.
+
+Method of Communication
+-----------------------
+
+Most official committee business takes place via the
+`ghc-steering-commitee <https://mail.haskell.org/mailman/listinfo/ghc-steering-committee>`_ mailing list. The archives of this list are public, and
+any member of the community may subscribe. It is intended that the list
+be used by the committee, though community members might be asked
+to post there during relevant conversations.
+
+Any business not on the public mailing list will be of a sensitive nature,
+most likely pertaining to individuals. In particular, discussions of selecting
+new members and of violations of the guidelines for respectful communication
+will not appear on the mailing list.
+
+Term Limits and Committee Selection
+-----------------------------------
+
+Any community thrives best by continuing to refresh itself with new members.
+The main criteria for becoming a member of the committee are:
+
+ * A track record of constructive contribution to public discussion of GHC proposals
+ * A track record of constructive contribution to one or more of the communities outlined above (users, tool authors etc)
+ * An expressed willingness to respond to GHC proposals in a timely manner.
+
+These criteria are not exhaustive -- nominations and self-nominations are free
+to strengthen the case in whatever way they deem appropriate --- but a record
+of thoughtful contribution in a public space carries the most weight.
+
+Membership on the committee comes with a three-year term, extended so
+that a term expires only at the end of a nomination process. Call a
+member who has served for over three years an "expiring" member.
+A nomination process is triggered when the number of unexpiring members is
+about to drop below 9.
+
+When a nomination process is triggered, the secretary of
+the committee will put out a public call for nominations for people to join
+the committee. Nominations include a brief
+bio of the nominee and reasons why they would be appropriate for the
+committee. Self-nominations are welcome and expected. Expiring members are
+free to re-nominate themselves. 
+
+Continuing members of the committee vote on new membership via a ranked voting
+system; the precise details (i.e. election algorithm) are recommended by the
+secretary but can be vetoed by a majority vote. The ranking system includes a
+method for choosing multiple winners. It is expected that the committee
+favor newcomers in preference to re-nominated continuing members. If
+an expiring member continues, the secretary shall ensure that a
+rationale for this decision be published to the community. In all cases,
+an expiring member stays on the committee until the nomination process is complete.
+
+The voting process may result in a number of new members not equal to
+the number of outgoing members. This is fine; the size of the committee
+is not fixed.
+
+The nomination and voting process is kept private, by using direct
+email to committee members, not the mailing list. When the secretary's
+term is expiring (but that individual wishes to stay on the committee),
+one co-chair fills in for the secretary to run this process.
+
+Any member of the committee is free to step down at any time; such a member
+may choose to leave the committee immediately or to wait until the
+end of a nominating process (which would be triggered only when the number
+of unexpiring members drops below 9).
+
+There are two exceptions to the three-year term rule for two "key members"
+of the committee: in recognition of
+their historical and current importance to GHC, both Simon Peyton Jones
+and Simon Marlow will be expected to be retained on the committee when
+their terms end. If either wishes to continue serving on the committee
+when their terms end, and if the majority of the rest of the committee supports this outcome,
+no public nomination process needs to take place to replace them.
+
+These key members can be stripped of their status as key members by a
+majority vote of the committee, and other individuals can be made into
+key members by a unanimous decision of the committee. In both cases,
+changes to the list of key members will be accompanied by a public
+rationale.
+
+There is no process for members of the public at large to
+directly add or remove committee members. (That is, there is no public
+vote.) Representative voting across the internet is fraught, and the
+drawbacks to such a system seem to outweigh any benefits. It is expected
+that a misbehaving committee (say, one that selects only its friends and
+ignores other nominations) loses legitimacy and is publicly called into
+question in an attempt to make changes for the better in its operation.