Skip to content

Commit 9df8393

Browse files
mhdawsonmhdawson
committed
doc: charter the Release and LTS working group
part 1 - governance and docs for repo PR-URL: #223 Fixes: #48 Reviewed-By: Sam Roberts <[email protected]> Reviewed-By: Richard Lau <[email protected]> Reviewed-By: MichaëZasso <[email protected]> Reviewed-By: Gibson Fahnestock <[email protected]> Reviewed-By: Myles Borins <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Jeremiah Senkpiel <[email protected]> Reviewed-By: Bartosz Sosnowski <[email protected]> Reviewed-By: Rod Vagg <[email protected]>
1 parent d9cb7b3 commit 9df8393

3 files changed

Lines changed: 235 additions & 14 deletions

File tree

‎CONTRIBUTING.md‎

Lines changed: 38 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,38 @@
1+
<a id="developers-certificate-of-origin"></a>
2+
## Developer's Certificate of Origin 1.1
3+
4+
By making a contribution to this project, I certify that:
5+
6+
* (a) The contribution was created in whole or in part by me and I
7+
have the right to submit it under the open source license
8+
indicated in the file; or
9+
10+
* (b) The contribution is based upon previous work that, to the best
11+
of my knowledge, is covered under an appropriate open source
12+
license and I have the right under that license to submit that
13+
work with modifications, whether created in whole or in part
14+
by me, under the same open source license (unless I am
15+
permitted to submit under a different license), as indicated
16+
in the file; or
17+
18+
* (c) The contribution was provided directly to me by some other
19+
person who certified (a), (b) or (c) and I have not modified
20+
it.
21+
22+
* (d) I understand and agree that this project and the contribution
23+
are public and that a record of the contribution (including all
24+
personal information I submit with it, including my sign-off) is
25+
maintained indefinitely and may be redistributed consistent with
26+
this project or the open source license(s) involved.
27+
28+
29+
### Moderation Policy
30+
31+
The [Node.js Moderation Policy] applies to this WG.
32+
33+
### Code of Conduct
34+
35+
The [Node.js Code of Conduct][] applies to this WG.
36+
37+
[Node.js Code of Conduct]: https://github.com/nodejs/TSC/blob/master/CODE_OF_CONDUCT.md
38+
[Node.js Moderation Policy]: https://github.com/nodejs/TSC/blob/master/Moderation-Policy.md

‎GOVERNANCE.md‎

Lines changed: 127 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,127 @@
1+
# Release Working Group
2+
3+
The Node.js Release Working Group (WG) maintains oversight
4+
over the Node.js Release, Long Term Support (LTS) and
5+
Canary in the Gold Mine (CitGM) teams. It manages the release
6+
and long term support schedule and policies for all Node.js releases.
7+
8+
The WG has final authority over Releases including:
9+
10+
* Release process and tools.
11+
* Content for all releases.
12+
* Schedule for all releases.
13+
* Contribution policy for the Release repository.
14+
* Conduct guidelines for the Working group.
15+
* Administration of Long Term Support policy for all releases.
16+
17+
For the current list of WG members, see the project README.md.
18+
19+
## Collaborators
20+
21+
The Release GitHub repository is maintained by the WG (all WG
22+
members are Collaborators for the Release repository) and additional
23+
Collaborators who are added by the WG on an ongoing basis.
24+
25+
Individuals making significant and valuable contributions are made
26+
Collaborators and given commit-access to the Release repository.
27+
These individuals are identified by the WG and their addition
28+
as Collaborators is discussed during the WG meeting.
29+
30+
**Note**: If you make a significant contribution and are not considered for
31+
commit access, log an issue or contact a WG member directly and it will
32+
be brought up in the next WG meeting.
33+
34+
Modifications of the contents of the Release repository are made
35+
on a collaborative basis. Anybody with a GitHub account may propose a
36+
modification via pull request and it will be considered by the project
37+
Collaborators. All pull requests must be reviewed and accepted by a
38+
Collaborator with sufficient expertise who is able to take full responsibility
39+
for the change. In the case of pull requests proposed by an existing
40+
Collaborator, an additional Collaborator is required for sign-off. Consensus
41+
should be sought if additional Collaborators participate and there is
42+
disagreement around a particular modification. See Consensus Seeking
43+
Process below for further detail on the consensus model used for governance.
44+
45+
Collaborators may opt to elevate significant or controversial modifications,
46+
or modifications that have not found consensus to the WG for discussion by
47+
assigning the WG-agenda tag to a pull request or issue. The WG should serve
48+
as the final arbiter where required.
49+
50+
## WG Membership
51+
52+
WG seats are not time-limited. There is no fixed size of the WG.
53+
54+
There is no specific set of requirements or qualifications
55+
for WG membership beyond these rules.
56+
57+
The WG may add additional members to the WG by consensus(defined
58+
as no objections, more than 50% of the members participating in the
59+
discussion, and all those participating in the discussion agreeing).
60+
61+
A WG member may be removed from the WG by voluntary resignation,
62+
or by unanimous consensus of all other WG members. If a member is
63+
removed from the WG then they are also removed from all WG teams
64+
(including the Releasers team).
65+
66+
Changes to WG membership should be posted in the agenda, and may be
67+
suggested as any other agenda item (see "WG Meetings" below).
68+
69+
If an addition or removal is proposed during a meeting, and the full WG
70+
is not in attendance to participate, then the addition or removal is
71+
added to the agenda for the subsequent meeting. This is to ensure
72+
that all members are given the opportunity to participate in all
73+
membership decisions. If a WG member is unable to attend a meeting
74+
where a planned membership decision is being made,
75+
then their consent is assumed.
76+
77+
No more than 1/3 of the voting WG members may be affiliated with the same
78+
employer. If removal or resignation of a WG member, or a change of
79+
employment by a WG member, creates a situation where more than 1/3
80+
of the WG membership shares an employer, then the situation must be
81+
immediately remedied by the resignation or removal of one or more
82+
WG members affiliated with the over-represented employer(s).
83+
84+
## WG Meetings
85+
86+
The WG meets regularly, check the foundation calendar for details.
87+
One of the WG members will volunteer to act as the moderator
88+
for each meeting subject to agreement from the rest of the
89+
members. Each meeting should be published to YouTube.
90+
91+
Items are added to the WG agenda that are considered contentious or are
92+
modifications of governance, contribution policy,
93+
WG membership, or release process.
94+
95+
The intention of the agenda is not to approve or review all patches;
96+
that should happen continuously on GitHub and be handled
97+
by the larger group of Collaborators.
98+
99+
Any community member or contributor can ask that something be
100+
added to the next meeting's agenda by logging a GitHub Issue.
101+
Any Collaborator, WG member or the moderator can add the item
102+
to the agenda by adding the WG-agenda tag to the issue.
103+
104+
Prior to each WG meeting the moderator will share the Agenda with
105+
members of the WG. WG members can add any items they like to the
106+
agenda at the beginning of each meeting.
107+
108+
The WG may invite persons or representatives from certain
109+
projects to participate in a non-voting capacity.
110+
111+
The moderator is responsible for summarizing the discussion of
112+
each agenda item and sends it as a pull request after the meeting.
113+
114+
## Consensus Seeking Process
115+
116+
The WG follows a Consensus Seeking decision-making model.
117+
118+
When an agenda item has appeared to reach a consensus the moderator
119+
will ask "Does anyone object?" as a final call for dissent from the consensus.
120+
121+
If an agenda item cannot reach a consensus a WG member can call for either a
122+
closing vote or a vote to table the issue to the next meeting. The call for
123+
a vote must be seconded by a majority of the WG or else the
124+
discussion will continue. Simple majority wins.
125+
126+
Note that changes to WG membership require unanimous consensus.
127+
See "WG Membership" above.

‎README.md‎

Lines changed: 70 additions & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
1-
# Node.js Long-term Support Working Group
1+
# Node.js Release Working Group
22

3-
# LTS schedule<sup>1</sup>
3+
## Release schedule<sup>1</sup>
44

55
| Release | LTS Status | Codename | Active LTS Start | Maintenance Start | Maintenance End |
66
| :--: | :---: | :---: | :---: | :---: | :---: |
@@ -14,7 +14,7 @@
1414
| 9.x |No LTS | | | | |
1515
| 10.x |**Pending** | Pending | October 2018 | April 2020 | April 2021 |
1616

17-
* <sup>1</sup>: All scheduled dates are subject to change by the Node.js LTS
17+
* <sup>1</sup>: All scheduled dates are subject to change by the Node.js Release
1818
working group or Node.js Core Technical Committee.
1919
* <sup>2</sup>: The 8.x *Maintenance* LTS cycle is currently scheduled to expire
2020
early on December 31, 2019 to align with the scheduled End-of-Life of
@@ -23,10 +23,48 @@
2323

2424
<p><img src="schedule.png" alt="LTS Schedule"/></p>
2525

26-
The LTS Schedule is available also as a [JSON][] file or [ICal][]. There is
26+
The Release schedule is available also as a [JSON][] file or [ICal][]. There is
2727
also a live [Google Calendar][] that may be subscribed to.
2828

29-
# LTS Plan
29+
## Mandate
30+
31+
The Release working group's purpose is:
32+
33+
* Management/execution of the release and support process for all releases.
34+
35+
Its responsibilities are:
36+
37+
* Define the release process.
38+
* Define the content of releases.
39+
* Generate and create releases.
40+
* Test Releases
41+
* Manage the LTS and Current branches including backporting changes to
42+
these branches.
43+
* Define the policy for what gets backported to release streams.
44+
45+
The Release working group is structured into teams and membership in
46+
the working group does not automatically result in membership in these
47+
teams. These teams are:
48+
49+
* Releasers team
50+
* LTS team
51+
* CITGM team
52+
53+
The `releasers` team is entrusted with the secrets and CI access to be able
54+
build and sign releases. **Additions to the releasers team must be approved
55+
by the CTC.**
56+
57+
The Long Term Support (LTS) team manages the process/content of LTS releases
58+
and the required backporting for these releases. Additions to the LTS
59+
team needs sign off from the rest of the LTS team.
60+
61+
The Canary in the Gold Mine (CITGM) team maintains CITGM as one of
62+
the key sanity checks for releases. This team maintains the CITGM
63+
repository and works to keep CITGM builds running and passing regularly.
64+
This also includes maintaining the CI jobs in collaboration with the Build
65+
Working Group.
66+
67+
## Release Plan
3068

3169
New semver-major releases of Node.js are cut from `master` every six months.
3270
New even-numbered versions (e.g. v6, v8, v10, etc) are cut in April. New
@@ -48,7 +86,7 @@ Given this schedule, there will be no more than two active LTS releases at any
4886
given time, overlapping for a maximum period of six months.
4987

5088
Once a major version enters LTS coverage, new features (semver-minor) may only
51-
be landed with consent of the CTC and the LTS Working Group. No semver-major
89+
be landed with consent of the Release working group. No semver-major
5290
changes other than those required for critical security fixes may be landed.
5391

5492
Changes in an LTS-covered major version are limited to:
@@ -66,7 +104,7 @@ Changes in an LTS-covered major version are limited to:
66104

67105
Generally changes are expected to live in a *Current* release for at least 2
68106
weeks before being backported. It is possible for a commit to land earlier at
69-
the discretion of the LTS Working Group and the maintainers of the LTS branches.
107+
the discretion of the Release working group and the maintainers of the LTS branches.
70108

71109
Once a release moves into Maintenance mode, only ***critical*** bugs,
72110
***critical*** security fixes, and documentation updates will be permitted.
@@ -76,14 +114,14 @@ Note that while it is possible that critical security and bug fixes may lead to
76114
rare and will land as *semver-minor* bumps in the LTS covered version.
77115

78116
All LTS releases will be assigned a "codename" drawn from the names of elements
79-
on the Periodic Table of Elements. For each upcoming LTS release, the LTS
80-
Working Group will select a handful of candidate names and submit those for a
117+
on the Periodic Table of Elements. For each upcoming LTS release, the Release
118+
working group will select a handful of candidate names and submit those for a
81119
collaborator vote.
82120

83121
An odd-numbered major release will cease to be actively updated when the
84122
subsequent even-numbered major release is cut.
85123

86-
## LTS Staging Branches
124+
### LTS Staging Branches
87125

88126
Every LTS major version has two branches in the GitHub repository: a release
89127
branch and a staging branch. The release branch is used to cut new releases.
@@ -98,7 +136,7 @@ commits are backported for a future Node.js v4 release, those must come in the
98136
form of pull requests opened against the `v4.x-staging` branch. **Commits are
99137
only landed in the `v4.x` branch when a new `v4.x` release is being prepared.**
100138

101-
## Node abstraction layer
139+
### Node abstraction layer
102140

103141
It should be stated that the abstraction layer (currently [`NAN`][]) should
104142
support all *current* LTS releases. Given that Active LTS will overlap
@@ -114,14 +152,32 @@ any given point in time, fully support a maximum of 2 LTS releases.
114152
[ICal]: schedule.ical
115153
[`NAN`]: https://github.com/nodejs/nan
116154

117-
## LTS Team members
155+
The working group members are the union of the LTS, Releasers
156+
and CITGM team members listed below.
118157

158+
## LTS Team members
119159
* Gibson Fahnestock [@gibfahn](https://github.com/gibfahn)
120160
* James M Snell [@jasnell](https://github.com/jasnell)
121161
* Jeremiah Senkpiel [@Fishrock123](https://github.com/Fishrock123)
122162
* Michael Dawson [@mhdawson](https://github.com/mhdawson)
123163
* Myles Borins [@MylesBorins](https://github.com/MylesBorins)
124-
* Rod Vagg [@rvagg](https://github.com/rvagg)
125164
* Sam Roberts [@sam-github](https://github.com/sam-github)
126165

127-
Github team for LTS: https://github.com/orgs/nodejs/teams/lts
166+
### Releasers team
167+
* Colin Ihrig [@cjihrig](https://github.com/cjihrig)
168+
* Evan Lucas [@evanlucas](https://github.com/evanlucas)
169+
* Italo A. Casas [@italoacasas](https://github.com/italoacasas)
170+
* James M Snell [@jasnell](https://github.com/jasnell)
171+
* Jeremiah Senkpiel [@Fishrock123](https://github.com/Fishrock123)
172+
* Myles Borins [@MylesBorins](https://github.com/MylesBorins)
173+
* Rod Vagg [@rvagg](https://github.com/rvagg)
174+
175+
### CITGM team
176+
* Bartosz Sosnowski [@bzoz](https://github.com/bzoz)
177+
* Bryan English [@bengl](https://github.com/bengl)
178+
* George Adams [@gdams](https://github.com/gdams)
179+
* Gibson Fahnestock [@gibfahn](https://github.com/gibfahn)
180+
* James M Snell [@jasnell](https://github.com/jasnell)
181+
* Michaël Zasso [@targos](https://github.com/targos)
182+
* Myles Borins [@MylesBorins](https://github.com/MylesBorins)
183+
* Richard Lau [@richardlau](https://github.com/richardlau)

0 commit comments

Comments
 (0)