Chartering the Release Team as a Working Group

[jasnell]

The Release Team has always been rather informal. There would likely be value in having an official working group to encourage better coordination across releases (even possibly establishing a more predictable release schedule).

/cc @nodejs/ctc @nodejs/release

[mcollina]

👍

[targos]

+1

[mhdawson]

Could you provide a draft of the mandate for the Release WG so that we can see how it compares to that of the LTS WG (which I know is not formally charted but I think there was a mandate defined at one point)

[jasnell]

Fundamentally, the Release WG would be responsible for:

1. Managing the process for creating a release (e.g. the managing process defined in `/doc/releases.md')
2. Defining and managing the release schedule. When such changes have an impact on LTS cycles, coordination with the LTS Working Group is expected.
3. Preparing and cutting all releases for all branches. For branches under LTS, this would be done in coordination with the LTS Working Group.
4. Management of release keys.

The membership of the Release WG would consist of everyone currently on the @nodejs/release team. New members would be added through consensus of the existing release team members (making CTC vote and review of these unnecessary unless there is contention).

For Current, the Release WG would generally have full control over the release cycle.
For LTS, the LTS WG would determine the schedule for LTS releases, but would work with the Release WG to actually cut the release. There is currently membership overlap between these teams so it is not anticipated that any coordination issues would arise.

[cjihrig]

I can't honestly say I see a need for a chartered release working group. Most of the interesting work that would happen here should likely fall on the LTS group anyway.

[jasnell]

For 99.99% of the day to day, nothing would change. The two areas of impact would be (a) adding new releasers would fall on the existing releasers and would not require CTC input and (b) the release team would have the ability to determine the entire release schedule, including matters like the 8.0.0 delay that we just went through, also without requiring CTC input. Fundamentally, the idea is to empower the release team to operate more autonomously with fewer decisions having to bubble up to the CTC.

[cjihrig]

(a) seems like it could easily be delegated to the existing release team without chartering. And if not, it very rarely comes up.
(b) cases like the 8.0.0 delay were significant enough that the entire CTC should have weighed in. It also falls mostly to the LTS team.

Th release process is obviously important, but I don't think the team itself needs to become a working group. Maybe it could be combined with LTS.

[jasnell]

I can certainly see a path that essentially moves the Release Team under the LTS Working Group. That would certainly simplify matters and make it easier to coordinate.

[gibfahn]

Th release process is obviously important, but I don't think the team itself needs to become a working group. Maybe it could be combined with LTS.

I think it makes sense to keep the nodejs/release team, even if they become a subset of LTS. It's useful for people to be able to get involved with LTS and backporting without having to have release powers.

On a related note, I always found it weird that LTS handles the LTS releases but not the Current releases. I think there's enough overlap between them to warrant handling it in one group.

[jasnell]

Yes, the release team would definitely remain. That, I believe is not in question.

[MylesBorins]

Seems to me like release should be chartered with LTS below it. Thoughts?

…

On May 11, 2017 1:25 AM, "James M Snell" ***@***.***> wrote: Yes, the release team would definitely remain. That, I believe is not in question. — You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub <#123 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAecV6a4NY7jPGfJuXQfFm98wh91ymIiks5r4jlkgaJpZM4NW0T1> .

[jasnell]

I think the LTS WG actually has a broader mission. What I'm thinking now is that LTS WG should evolve into "Release and Support WG" with two distinct teams under: Backport and Release.

[sam-github]

I agree with above, it mirrors how I see the types of work

• cherry-picking and backporting commits from master to Current or to LTS, it seems to me that these activities are similar whether the target is Current or LTS, and we sometimes discuss in LTS things like the exact metadata to use, which is something that should be identical whether PRs are backported to Current or to LTS, so this seems like it should be one group

• actually cutting releases, which requires special permissions, keys, and doesn't require someone to be familiar with what is in the release, or how the release branch was built, but does require special knowledge or our infrastructure

[sam-github]

As for charterting, the first WGs were chartered, but I think at this point there appears to be no advantage to chartering, and newer WGs aren't bothering. An unchartered group can have a CoC, a membership, a github repo under nodejs, etc. Chartering seems to involve more process for no particular gain. If only chartered groups could access some particular resource (a standalone repo, a vote on TSC, .... something), there would be some reason to charter. I'm not for or against, since it doesn't have any effect that I can see.

[nebrius]

An unchartered group can have a CoC, a membership, a github repo under nodejs, etc.

Actually....they can't have their own CoC. Technically speaking, teams are not autonomous and the CTC/TSC can decide at a whim to ignore the team and make decisions for them. This is not the case with WG's though. The key thing a charter does, besides define process, is to declare the areas of autonomy from the CTC/TSC which are binding. This isn't typically an issue in practice, since we strive for consensus, but it could matter if the WG and CTC can't come to a consensus on an issue.