diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 00000000..3c467fc6 --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,39 @@ + +## 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 + diff --git a/GOVERNANCE.md b/GOVERNANCE.md new file mode 100644 index 00000000..db9c7379 --- /dev/null +++ b/GOVERNANCE.md @@ -0,0 +1,127 @@ +# Release Working Group + +The Node.js Release Working Group (WG) maintains oversight +over the Node.js Release, Long Term Support (LTS) and +Canary in the Gold Mine (CitGM) teams. It manages the release +and long term support schedule 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. +* Administration of Long Term Support policy for all releases. + +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 repository) 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 Release repository. +These individuals are identified by the WG and their addition +as Collaborators is discussed during the 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 consensus(defined +as no objections, more than 50% of the members participating in the +discussion, and all those participating in the discussion agreeing). + +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 regularly, check the foundation calendar for details. +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. + +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 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. diff --git a/README.md b/README.md index aafe0541..7e5ce851 100644 --- a/README.md +++ b/README.md @@ -1,6 +1,6 @@ -# Node.js Long-term Support Working Group +# Node.js Release Working Group -# LTS schedule1 +## Release schedule1 | Release | LTS Status | Codename | Active LTS Start | Maintenance Start | Maintenance End | | :--: | :---: | :---: | :---: | :---: | :---: | @@ -14,7 +14,7 @@ | 9.x |No LTS | | | | | | 10.x |**Pending** | Pending | October 2018 | April 2020 | April 2021 | -* 1: All scheduled dates are subject to change by the Node.js LTS +* 1: All scheduled dates are subject to change by the Node.js Release working group or Node.js Core Technical Committee. * 2: The 8.x *Maintenance* LTS cycle is currently scheduled to expire early on December 31, 2019 to align with the scheduled End-of-Life of @@ -23,10 +23,48 @@

LTS Schedule

-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 and support process for all releases. + +Its responsibilities are: + +* Define the release process. +* Define the content of releases. +* Generate and create releases. +* Test Releases +* Manage the LTS and Current branches including backporting changes to + these branches. +* Define the policy for what gets backported to release streams. + +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. Additions to the LTS +team needs sign off from the rest of the LTS team. + +The Canary in the Gold Mine (CITGM) team maintains CITGM as one of +the key sanity checks for releases. This team maintains the CITGM +repository and works to keep CITGM builds running and passing regularly. +This also includes maintaining the CI jobs in collaboration with the Build +Working Group. + +## Release 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 +86,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 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 +104,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 +114,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 +136,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 +152,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 [@cjihrig](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 +* Bartosz Sosnowski [@bzoz](https://github.com/bzoz) +* Bryan English [@bengl](https://github.com/bengl) +* George Adams [@gdams](https://github.com/gdams) +* Gibson Fahnestock [@gibfahn](https://github.com/gibfahn) +* James M Snell [@jasnell](https://github.com/jasnell) +* Michaël Zasso [@targos](https://github.com/targos) +* Myles Borins [@MylesBorins](https://github.com/MylesBorins) +* Richard Lau [@richardlau](https://github.com/richardlau)