Suggestion: drop backporters team?

[BethGriggs]

At the moment, everyone in the backporters team is also in the lts team. I'm not sure the distinction is still necessary (often enough @nodejs/lts is notified in PRs).

I'd suggest reducing down to LTS, Releasers, and CITGM teams, thoughts?

[targos]

sgtm

[MylesBorins]

The one challenge I would see with this is that the LTS team has far more people on it than the backporters team and there is a single discrepancy @addaleax is on backporters but not lts.

We also use backporters for basic IAM, in that no one but that team can push to vX.x-staging branches.

So I would be in favor of this change but we would likely need to do the following

• remove inactive members for the lts team
• add @addaleax to the lts team
• update IAM for branch protection
• then remove backporters team

To be clear, I'm very much in favor of simplify team structure as well as pruning inactive folks!

[sam-github]

I don't think backporters have ever landed on vx.y-staging branches, at least, I never have, don't know about @addaleax

I didn't realize I was on nodejs/lts, I thought I was just on nodejs/backporters. I self-removed from both teams.

[MylesBorins]

I've just double checked and it looks like the branch protection is not on the .x-staging branches after all, my mistake. I'm now recalling that we removed it because in the past it enforced no force-pushes which breaks our workflow.

This is now no longer and issue, but would be a good idea to enforce this policy after we sort out team membership

[MylesBorins]

also FWIW

https://github.com/nodejs/Release#lts-staging-branches documents the policy which will need to be updated

[MylesBorins]

I've opened #549 to work on cleaning up the LTS list.

One thing that does strike me is that after removing backporters we won't really have a group for folks who want to participate in Release but not necessarily only work on LTS... it might make sense for us to completely rethink the structure of the group and how we use it for permissions. Right now we have

• Release
  • LTS (Only those in this group can do LTS releases)
    • Backporters (Only those in this group can land on v.x-staging for LTS)
  • Releasers (Only those in this group can do releases)
  • CITGM (Only those in this group can manage the CITGM repo)

Release itself has no members, only child members. Perhaps the current structure that we have doesn't make a ton of sense, since we have a mixture of IAM related roles and collaborative roles... and not a really great story for those who are ramping up or want to be more involved on a policy side. So here's a shot in the dark at what an alternative Structure could look like (names to be bikeshedded):

• Release (Top-Level group, no direct membership)
  • release-working-group-members (anyone who is a member of the working group is in this team)
  • release-automation (members of this team have push access to all repos that handle release automation including changelog-maker, branch-diff, node-core-utils?, citgm)
  • releasers (members of this team have access to make releases)
  • lts (group specifically focused on lts releated work, additional IAM specific to LTS branches)

Thoughts?

[mhdawson]

I like the suggested naming.

[BethGriggs]

@MylesBorins I was thinking of a similar structure. A few thoughts:

• Do (or did?) changelog-maker, branch-diff, node-core-utils, etc. fall under the remit of the @nodejs/automation team? We should check how active that team is as I'm not sure it makes sense to have two teams with the responsibility of those tools.
• Out of the proposed teams, which would have permission to land items on the staging branches?
• Do we want to continue to distinguish between releasers and LTS releasers? And would that be denoted by being a member of releasers && lts in your proposed structure?

[MylesBorins]

Do (or did?) changelog-maker, branch-diff, node-core-utils, etc. fall under the remit of the @nodejs/automation team? We should check how active that team is as I'm not sure it makes sense to have two teams with the responsibility of those tools.

It looks like those three repos currently fall under https://github.com/orgs/nodejs/teams/automation-collaborators

It currently has 5 members and 5 child team members with a large overlap of current + emeritus members of release. Pinging @nodejs/automation-collaborators to chime in here about there. The automation team itself is larger, but does not explicitly have permission. It seems like a bunch of folks have been given direct commit access rather than via IAM.

FWIW I don't think it makes sense to duplicate the efforts, but I'm not convinced that managing some of the IAM over here is such a terrible idea either considering how it is currently setup.

Out of the proposed teams, which would have permission to land items on the staging branches?

Current staging ~ all collaborators
Current .x ~ all releasers
LTS staging ~ LTS
LTS releases ~ LTS && releasers

Do we want to continue to distinguish between releasers and LTS releasers? And would that be denoted by being a member of releasers && lts in your proposed structure?

I'm questioning this myself. I think that there is a benefit that we can onboard people to handle releases without onboarding for LTS... but also in support of simplifying the process and more broadly sharing the load. What i do think is important is to maintain the ability for folks to backport without committing to do releases.

[rvagg]

changelog-maker & branch-diff were originally my personal projects, moved to this org and I've continued to be primary maintainer, mainly out of momentum, with Myles also putting in a fair bit to changelog-maker in recent time. I don't think the automation team has really embraced them, probably because it's not a super active team and they were given to that team because it seemed to be a logical fit at the time. I'm fine with wherever they go if they find a group of people that want to care for them. Releasers seems like a logical group since you're the primary consumers in this org (I also use them in node-gyp but not as heavily as you all do).

[joyeecheung]

Yes, so far I think most automation projects are maintained by individuals who have access and the commit access is not granted with teams - automation-collaborators is more like "TSC/TSC emeritus who also spend time on automation" (then they already have commit access to these repos anyway), rather than "automation team members who are given commit access to these repos".

[joyeecheung]

Also based on the activity of automation team, I think it probably makes more sense to disband it now in favor of smaller teams for individual projects. We don't have meetings over there, the gitter channel is not active, and a lot of the work done in the automation projects are by Node.js collaborators who are not in that team anyway.

[BethGriggs]

We discussed this in the Release WG meeting today - #551

There are still lots of open questions including:

• Who should have permission to land things on the branches?
• Who should be able to participate in the decision around what should land in LTS?

It looks like, based on @joyeecheung comments, one first step we could come to agreement on is creating a release-automation team that collectively looks after citgm, changelog-maker, branch-diff, node-core-utils. Should we spin up a separate issue to cover/discuss that specific change?

[BethGriggs]

This is pretty stale and I don't think anything else needs to happen here. The last suggestion of granting releasers maintainer access to release-related tooling is covered by #557.