doc: charter the Release working group

CONTRIBUTING.md

@@ -0,0 +1,39 @@
+<a id="developers-certificate-of-origin"></a>
+## Developer's Certificate of Origin 1.1
+
+By making a contribution to this project, I certify that:
+
+    * (a) The contribution was created in whole or in part by me and I
+      have the right to submit it under the open source license
+      indicated in the file; or
+
+    * (b) The contribution is based upon previous work that, to the best
+      of my knowledge, is covered under an appropriate open source
+      license and I have the right under that license to submit that
+      work with modifications, whether created in whole or in part
+      by me, under the same open source license (unless I am
+      permitted to submit under a different license), as indicated
+      in the file; or
+
+    * (c) The contribution was provided directly to me by some other
+      person who certified (a), (b) or (c) and I have not modified
+      it.
+
+    * (d) I understand and agree that this project and the contribution
+      are public and that a record of the contribution (including all
+      personal information I submit with it, including my sign-off) is
+      maintained indefinitely and may be redistributed consistent with
+      this project or the open source license(s) involved.
+
+
+### Moderation Policy
+
+The [Node.js Moderation Policy] applies to this WG.
+
+### Code of Conduct
+
+The [Node.js Code of Conduct][] applies to this WG.
+
+[Node.js Code of Conduct]: https://github.com/nodejs/TSC/blob/master/CODE_OF_CONDUCT.md
+[Node.js Moderation Policy]: https://github.com/nodejs/TSC/blob/master/Moderation-Policy.md
+

GOVERNANCE.md

@@ -0,0 +1,129 @@
+# Release Working Group
+
+The Node.js Release Working Group (WG) maintains oversight
+over the Node.js Release and Long Term Support (LTS) teams. It
+manages the release and long term support shedule and policies
+for all Node.js releases.
+
+The WG has final authority over Releases including:
+
+* Release process and tools.
+* Content for all releases.
+* Schedule for all releases.
+* Contribution policy for the Release repository.
+* Conduct guidelines for the Working group.
+
+For the current list of WG members, see the project README.md.
+
+## Collaborators
+
+The Release GitHub repository is maintained by the WG (all WG
+members are Collaborators for the Release respository) and additional
+Collaborators who are added by the WG on an ongoing basis.
+
+Individuals making significant and valuable contributions are made
+Collaborators and given commit-access to the project. These individuals
+are identified by the WG and their addition as Collaborators is discussed
+during the weekly WG meeting.
+
+**Note**: If you make a significant contribution and are not considered for
+commit-access, log an issue or contact a WG member directly and it will
+be brought up in the next WG meeting.
+
+Modifications of the contents of the Release repository are made 
+on a collaborative basis.  Anybody with a GitHub account may propose a
+modification via pull request and it will be considered by the project
+Collaborators. All pull requests must be reviewed and accepted by a
+Collaborator with sufficient expertise who is able to take full responsibility
+for the change. In the case of pull requests proposed by an existing
+Collaborator, an additional Collaborator is required for sign-off. Consensus
+should be sought if additional Collaborators participate and there is
+disagreement around a particular modification. See Consensus Seeking
+Process below for further detail on the consensus model used for governance.
+
+Collaborators may opt to elevate significant or controversial modifications,
+or modifications that have not found consensus to the WG for discussion by
+assigning the WG-agenda tag to a pull request or issue. The WG should serve
+as the final arbiter where required.
+
+## WG Membership
+
+WG seats are not time-limited. There is no fixed size of the WG.
+
+There is no specific set of requirements or qualifications
+for WG membership beyond these rules.
+
+The WG may add additional members to the WG by unanimous consensus.
+
+A WG member may be removed from the WG by voluntary resignation,
+or by unanimous consensus of all other WG members. If a member is
+removed from the WG then they are also removed from all WG teams
+(including the Releasers team).
+
+Changes to WG membership should be posted in the agenda, and may be
+suggested as any other agenda item (see "WG Meetings" below).
+
+If an addition or removal is proposed during a meeting, and the full WG
+is not in attendance to participate, then the addition or removal is
+added to the agenda for the subsequent meeting. This is to ensure
+that all members are given the opportunity to participate in all
+membership decisions. If a WG member is unable to attend a meeting
+where a planned membership decision is being made,
+then their consent is assumed.
+
+No more than 1/3 of the voting WG members may be affiliated with the same
+employer. If removal or resignation of a WG member, or a change of
+employment by a WG member, creates a situation where more than 1/3
+of the WG membership shares an employer, then the situation must be
+immediately remedied by the resignation or removal of one or more
+WG members affiliated with the over-represented employer(s).
+
+## WG Meetings
+
+The WG meets every 3 weeks on a Google Hangout On Air. One of the
+WG members will volunteer to act as the moderator for each meeting
+subject to agreement from the rest of the members. Each meeting should be
+published to YouTube.
+
+Members of the `releasers` sub-team are not required to attend
+the WG meetings and maintain their WG membership simply by
+participating in the release process at least once a year.
+
+Items are added to the WG agenda that are considered contentious or are
+modifications of governance, contribution policy,
+WG membership, or release process.
+
+The intention of the agenda is not to approve or review all patches;
+that should happen continuously on GitHub and be handled
+by the larger group of Collaborators.
+
+Any community member or contributor can ask that something be
+added to the next meeting's agenda by logging a GitHub Issue.
+Any Collaborator, WG member or the moderator can add the item
+to the agenda by adding the WG-agenda tag to the issue.
+
+Prior to each WG meeting the moderator will share the Agenda with
+members of the WG. WG members can add any items they like to the
+agenda at the beginning of each meeting. The moderator and the WG
+cannot veto or remove items.
+
+The WG may invite persons or representatives from certain
+projects to participate in a non-voting capacity.
+
+The moderator is responsible for summarizing the discussion of
+each agenda item and sends it as a pull request after the meeting.
+
+## Consensus Seeking Process
+
+The WG follows a Consensus Seeking decision-making model.
+
+When an agenda item has appeared to reach a consensus the moderator
+will ask "Does anyone object?" as a final call for dissent from the consensus.
+
+If an agenda item cannot reach a consensus a WG member can call for either a
+closing vote or a vote to table the issue to the next meeting. The call for
+a vote must be seconded by a majority of the WG or else the
+discussion will continue. Simple majority wins.
+
+Note that changes to WG membership require unanimous consensus.
+See "WG Membership" above.

README.md

@@ -1,6 +1,6 @@
-# Node.js Long-term Support Working Group
+# Node.js Release Working Group
 
-# LTS schedule<sup>1</sup>
+## Release schedule<sup>1</sup>
 
 | Release |  LTS Status   | Codename | Active LTS Start | Maintenance Start | Maintenance End |
 |   :--:  |    :---:      |   :---:  |       :---:      |       :---:       |      :---:      |
@@ -23,10 +23,44 @@
 
 <p><img src="schedule.png" alt="LTS Schedule"/></p>
 
-The LTS Schedule is available also as a [JSON][] file or [ICal][]. There is
+The Release schedule is available also as a [JSON][] file or [ICal][]. There is
 also a live [Google Calendar][] that may be subscribed to.
 
-# LTS Plan
+## Mandate
+
+The Release working group's purpose is:
+
+* Management/execution of the release process for all releases.
+* Maintenance of the LTS releases.
+
+Its responsibilities are:
+
+* Define the release process.
+* Define the content for releases.
+* Generate and create releases. 
+* Manage the LTS and Current branches including backporting changes to 
+  these branches.
+
+The Release working group is structured into teams and membership in
+the working group does not automatically result in membership in these
+teams. These teams are:
+
+* Releasers team
+* LTS team
+* CITGM team
+
+The `releasers` team is entrusted with the secrets and CI access to be able
+build and sign releases.  **Additions to the releasers team must be approved
+by the CTC.**
+
+The Long Term Support (LTS) team manages the process/content of LTS releases
+and the required backporting for these releases.
+
+The CITGM team maintains CITGM as one of the key sanity checks for releases.
+This team maintains the CITGM implementation and works to keep CITGM
+builds running and passing regularly.
+
+## LTS Plan
 
 New semver-major releases of Node.js are cut from `master` every six months.
 New even-numbered versions (e.g. v6, v8, v10, etc) are cut in April. New
@@ -48,7 +82,7 @@ Given this schedule, there will be no more than two active LTS releases at any
 given time, overlapping for a maximum period of six months.
 
 Once a major version enters LTS coverage, new features (semver-minor) may only
-be landed with consent of the CTC and the LTS Working Group. No semver-major
+be landed with consent of the the Release working group. No semver-major
 changes other than those required for critical security fixes may be landed.
 
 Changes in an LTS-covered major version are limited to:
@@ -66,7 +100,7 @@ Changes in an LTS-covered major version are limited to:
 
 Generally changes are expected to live in a *Current* release for at least 2
 weeks before being backported. It is possible for a commit to land earlier at
-the discretion of the LTS Working Group and the maintainers of the LTS branches.
+the discretion of the Release working group and the maintainers of the LTS branches.
 
 Once a release moves into Maintenance mode, only ***critical*** bugs,
 ***critical*** security fixes, and documentation updates will be permitted.
@@ -76,14 +110,14 @@ Note that while it is possible that critical security and bug fixes may lead to
 rare and will land as *semver-minor* bumps in the LTS covered version.
 
 All LTS releases will be assigned a "codename" drawn from the names of elements
-on the Periodic Table of Elements. For each upcoming LTS release, the LTS
-Working Group will select a handful of candidate names and submit those for a
+on the Periodic Table of Elements. For each upcoming LTS release, the Release 
+working group will select a handful of candidate names and submit those for a
 collaborator vote.
 
 An odd-numbered major release will cease to be actively updated when the
 subsequent even-numbered major release is cut.
 
-## LTS Staging Branches
+### LTS Staging Branches
 
 Every LTS major version has two branches in the GitHub repository: a release
 branch and a staging branch. The release branch is used to cut new releases.
@@ -98,7 +132,7 @@ commits are backported for a future Node.js v4 release, those must come in the
 form of pull requests opened against the `v4.x-staging` branch. **Commits are
 only landed in the `v4.x` branch when a new `v4.x` release is being prepared.**
 
-## Node abstraction layer
+### Node abstraction layer
 
 It should be stated that the abstraction layer (currently [`NAN`][]) should
 support all *current* LTS releases. Given that Active LTS will overlap
@@ -114,14 +148,32 @@ any given point in time, fully support a maximum of 2 LTS releases.
 [ICal]: schedule.ical
 [`NAN`]: https://github.com/nodejs/nan
 
-## LTS Team members
+The working group members are the union of the LTS, Releasers
+and CITGM team members listed below.
 
+## LTS Team members
 * Gibson Fahnestock [@gibfahn](https://github.com/gibfahn)
 * James M Snell [@jasnell](https://github.com/jasnell)
 * Jeremiah Senkpiel [@Fishrock123](https://github.com/Fishrock123)
 * Michael Dawson [@mhdawson](https://github.com/mhdawson)
 * Myles Borins [@MylesBorins](https://github.com/MylesBorins)
-* Rod Vagg [@rvagg](https://github.com/rvagg)
 * Sam Roberts [@sam-github](https://github.com/sam-github)
 
-Github team for LTS: https://github.com/orgs/nodejs/teams/lts
+### Releasers team
+* Colin Ihrig [@cjhrig](https://github.com/cjihrig)
+* Evan Lucas [@evanlucas](https://github.com/evanlucas)
+* Italo A. Casas [@italoacasas](https://github.com/italoacasas)
+* James M Snell [@jasnell](https://github.com/jasnell)
+* Jeremiah Senkpiel [@Fishrock123](https://github.com/Fishrock123)
+* Myles Borins [@MylesBorins](https://github.com/MylesBorins)
+* Rod Vagg [@rvagg](https://github.com/rvagg)
+
+### CITGM team
+* James M Snell [@jasnell](https://github.com/jasnell)
+* Myles Borins [@MylesBorins](https://github.com/MylesBorins)
+* Gibson Fahnestock [@gibfahn](https://github.com/gibfahn)
+* George Adams [George Adams](https://github.com/gdams)
+* Bartosz Sosnowski [Bartosz Sosnowski](https://github.com/bzoz)
+* Richard Lau [Richard Lau](https://github.com/richardlau)
+* MichaëZasso [MichaëZasso](https://github.com/targos)
+* Bryan English [Bryan English](https://github.com/bengl)