Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

doc: charter the Release working group #223

Closed
wants to merge 17 commits into from
Closed

doc: charter the Release working group #223

Show file tree
Hide file tree
Changes from 2 commits
Commits
Show all changes
17 commits
Select commit Hold shift + click to select a range
052ba9f
doc: charter the Release and LTS working group
mhdawson Jun 1, 2017
47668c7
squash: fix nit
mhdawson Jun 1, 2017
624753d
squash: update based on discussion in last LTS meeting
mhdawson Jun 6, 2017
cf51ecc
squash: fix up naming of teams
mhdawson Jun 7, 2017
ff49030
squash: make all teams separate lists
mhdawson Jun 7, 2017
5ec8727
squash: address next comments
mhdawson Jun 7, 2017
245b46b
squash: address next set of comments
mhdawson Jun 19, 2017
d972b76
squash: address comments
mhdawson Jun 22, 2017
01c3c72
squash: address comments
mhdawson Jun 26, 2017
9f5348d
squash: address next set of comments
mhdawson Jul 5, 2017
4de70d7
squash: more fixup
mhdawson Jul 5, 2017
2e89ab5
squash: address comments
mhdawson Jul 6, 2017
7b5ffcd
squash: address comments
mhdawson Jul 14, 2017
4eabe3b
squash: address comments
mhdawson Jul 18, 2017
43c6d34
squash: address comments
mhdawson Aug 3, 2017
3e0022a
squash: address comments
mhdawson Aug 17, 2017
2a6c46a
squash: address comments
mhdawson Aug 24, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
39 changes: 39 additions & 0 deletions CONTRIBUTING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -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

125 changes: 125 additions & 0 deletions GOVERNANCE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,125 @@
# Release and LTS Working Group

The nodejs Release and LTS project is governed by a Working Group (WG) that
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Node.js

is responsible for high-level guidance of the project.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more. 

The Node.js Release and Support Working Group maintains oversight over the
Node.js Release and Long Term Support Teams, and manages the release and long
term support schedule and policies for all Node.js releases.

The Release and LTS stuff is not a "project"


The WG has final authority over this project including:

Technical direction
Project governance and process (including this policy)
Contribution policy
GitHub repository hosting
Conduct guidelines
Maintaining the list of additional Collaborators
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should these be a list?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure this list makes sense in the context of this WG.


For the current list of WG members, see the project README.md.

## Collaborators

The benchmarking GitHub repository is maintained by the WG and additional
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

benchmarking?

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is "the project" here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is the LTS repo to be remained to the Release repo. I'll change from project to Release repository.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

are identified by the WG and their addition as Collaborators is discussed
during the weekly WG meeting.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/weekly/

No longer a weekly meeting

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done


**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
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

missing comma after commit-access?

be brought up in the next WG meeting.

Modifications of the contents of the LTS and Release repository are made
on a collaborative basis. Anybody with a GitHub account may propose a
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are two spaces before Anybody, whereas elsewhere you use a single space.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

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.

For the current list of Collaborators, see the project README.md.

## WG Membership

WG seats are not time-limited. There is no fixed size of the WG. However,
the expected target is between 6 and 12, to ensure adequate coverage of
important areas of expertise, balanced with the ability to make
decisions efficiently.

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.

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).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should do a quick parse of the members list to make sure this isn't the case prior to ratification

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

agreed


## WG Meetings

The WG meets weekly on a Google Hangout On Air. A designated moderator
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe the current meeting frequency, at least for the LTS WG, is once every three weeks. I'm not sure about the Release team specifically.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the release team does not meet at all.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's never been a reason for the Release team to have a meeting and it's not clear there would need to be a reason after forming this WG. We should factor that in. We don't want to force process where none is needed.

approved by the WG runs the meeting. Each meeting should be
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a process for deciding the moderator?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we would need to define one

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 moderator and the WG
cannot veto or remove items.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can be done via consensus though right?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd like to just remove that line which I'll do.


The WG may invite persons or representatives from certain
projects to participate in a non-voting capacity.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are people able to ask for an invite?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think people can always ask. In terms of not being too specific I think I'd leave that out from here.


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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ditto.

See "WG Membership" above.
60 changes: 48 additions & 12 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
# Node.js Long-term Support Working Group
# Node.js Release and Long-term Support Working Group
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It feels like maintaining the LTS releases really falls under the greater umbrella of maintaining releases in general, so the WG could just be called Release WG.


# LTS schedule<sup>1</sup>
## LTS schedule<sup>1</sup>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this table contains non-LTS releases, though not fully documented, how about Release Schedule?

Or perhaps at this point a general Release table would be in order since this WG would now be responsible for all releases?


| Release | LTS Status | Codename | Active LTS Start | Maintenance Start | Maintenance End |
| :--: | :---: | :---: | :---: | :---: | :---: |
Expand All @@ -26,7 +26,42 @@
The LTS Schedule is available also as a [JSON][] file or [ICal][]. There is
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LTS working group is referred to above, I assume that should be either the Release working group or the LTS team.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

also a live [Google Calendar][] that may be subscribed to.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This section doesn't really seem necessary here


# LTS Plan
## Mandate

The Release and LTS working group's purpose is:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The WG should be made up of two distinct teams: The Release Team and the LTS/Backporting Team. Everything here should be cast in terms of splitting the responsibilities of the WG between those two teams


* Management/execution the release process for all releases.
* Maintenance of the LTS releases.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This line seems redundant given the previous line.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

removed


Its responsibilities are:

* Define the release process.
* Generate and create releases.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • Test Releases

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

* Manage the LTS and Current branches including backporting changes to
these branches.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does define support policy fall into this WG's responsibilities?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a line.

The Release and LTS working group is structured into teams and membership in
the working group does not automatically result in membership in these
teams. These teams are:

* Release team
* LTS team
* Backporting team
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The LTS team and Backporting team do not really need to be separate entities

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I 100% agree with this. The backporting team has been trained on how to backport and has specific permissions. Not everyone who is part of the LTS working group has that

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently the LTS responsibilities fall into two categories:

  1. Determining the LTS release schedule
  2. Deciding what goes into the LTS releases

The backporting team handles item 2. Both the release team and backporting teams can share responsibility for 1, meaning that we really only need two teams: backporting and release, who work together on the schedule.


The release team is entrusted with the secrets and CI access to be able
build and sign releases. **Additions to the release team must be approved
by the CTC.**

The LTS team manages the process/content of LTS releases as outlined in the
LTS plan. All members of the working group are members of the LTS team unless
they do not wish to be.

The backporting team is the team that does the ongoing work of porting
commits back to the LTS and Current branches. This team may consist of
collaborators from any of the Node.js working groups.


## LTS Plan
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The LTS plan should be a separate document that is not part of the charter. That way the WG can change it when it needs without having to modify the charter.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is the README.md for the repo. The charter the smaller section that defines its purpose and scope. Once that's agreed it will go into the doc in the CTC defining the WG's scope. We can chose to move the LTS plan out of the README.md for the repo but I don't think thats tied to chartering the WG.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The text below mentions odd releases, so maybe just call this Release plan

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

changed

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pushed changes to address comments.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm going to propose that I leave 1 more week for comments/objections here. Unless there are objections before the end of next week I'll add the ctc-review tag and request that the CTC review/approve


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
Expand Down Expand Up @@ -83,7 +118,7 @@ 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.
Expand All @@ -98,7 +133,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
Expand All @@ -114,14 +149,15 @@ 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
## Release and LTS Team members

* Colin Ihrig [@cjhrig](https://github.com/cjihrig)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would split these into distinct lists, even if there is overlap

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo: @cjhrig -> @cjihrig

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

* Evan Lucas [@evanlucas](https://github.com/evanlucas)
* Gibson Fahnestock [@gibfahn](https://github.com/gibfahn)
* James M Snell [@jasnell](https://github.com/jasnell)
* Jeremiah Senkpiel [@Fishrock123](https://github.com/Fishrock123)
* Italo A. Casas [@italoacasas](https://github.com/italoacasas) (release team)
* James M Snell [@jasnell](https://github.com/jasnell) (release team)
* Jeremiah Senkpiel [@Fishrock123](https://github.com/Fishrock123) (release team)
* Michael Dawson [@mhdawson](https://github.com/mhdawson)
* Myles Borins [@MylesBorins](https://github.com/MylesBorins)
* Rod Vagg [@rvagg](https://github.com/rvagg)
* Myles Borins [@MylesBorins](https://github.com/MylesBorins) (release team)
* Rod Vagg [@rvagg](https://github.com/rvagg) (release team)
* Sam Roberts [@sam-github](https://github.com/sam-github)

Github team for LTS: https://github.com/orgs/nodejs/teams/lts