Repo and npm accesses of related projects

[joyeecheung]

https://github.com/nodejs/core-validate-commit and https://github.com/nodejs/node-review (EDIT: also https://github.com/nodejs/branch-diff and https://github.com/nodejs/changelog-maker) have already been moved into the Node.js orgnization and there will be more repos get transferred later. (also the github bot is probably going to be handed over to the automation team as well). We need to figure out how to organize the accesses of these projects.

Repository access

Including write access(commit) and admin access(add new people).

A few options that I have in mind:

1. Form subteams that have write/admin accesses for each repo
2. Gives @nodejs/automation write access for all the repos, form a subteam of automation that has admin accesses (similar to how working groups organize things).
   • P.S. I noticed that at the moment not everyone in the automation team has turned on 2 factor authentication...personally I want to see people with write access turns it on, just to be safe.

If we do want to adopt the monorepo idea(see #1 (comment)), then after the transition we can probably just go with option 2.

NPM publish access

So first thing to do is to add the foundation account to the collaborator list as a safety net. We should keep the existing npm collaborators, other than that, I can think of a few options:

1. Add people from the subteams to the npm collaborator list
2. If we want a bigger team that works on code, then we can assign 1-2 people for each project that handle releases. (basically from Request for moving automation related projects into the foundation TSC#406 (comment))

Personally I would prefer to see the releasers turn on 2FA on their npm accounts as well.

So...

👍 if you want subteams with repo/npm accesses
😄 if you want a big team with repo accesses, and small teams of releasers for each project

Or discuss in this thread about any other ideas that you have!

[Tiriel]

Personnally, I'd go with "organizing things in a similar way to WG" to keep consistency throughout foundation.
And it doesn't give me any advantage since I'm not Collaborator, I guess. But it seems important to me that people with write access should not be everyone, and people with admin access be even more shortlisted.

Although, I'm not sure which emoji option represents that... second one I guess?

[joyeecheung]

@Tiriel If we want to keep the list of people having write access to all projects short, we can also form a subteam (automation-collaborators?) under automation that does that (similar to the collaborators team for core, not all people from members team are collaborators). The initial list can be people from TSC because...they are already owners of the whole organization so can access everything anyway.

[alopezsanchez]

I am with with @Tiriel. Personally, I'm a rookie here, so I'm not sure if I should have write access to all.
But, although I have no write access to a repo, it means that I can't make pull requests neither?

[joyeecheung]

@alopezsanchez These repos will be public so anyone can open pull requests.

[joyeecheung]

So another way to organize things is:

• automation (people who gets pinged, has write access to this repo and node-auto-test)
  • automation-admin (people with write/admin accesses to all related repos)
  • node-review (people who works on node-reviews, has write/admin access to that. npm releasers come from this team.)
  • ...other subteams for other projects

Alghough it does not work well with the monorepo idea...maybe subteams for releasers only?

[Tiriel]

@joyeecheung automation-collaborators seems good for me!

Being in the team is really cool, but I don't want to mess things up accidentally while I'm not yet full Collaborator.

IMHO your last org graph is cool, but should include this automation-collaborators team.
But I'll go with the majority vote anyway!

[JasonEtco]

I'm +1 for having a two-team structure, "collaborators/maintainers" who can merge in PRs, and other folks who are acknowledged as being regular contributors.

As for npm releases, I think there should either be an automated system for publishing (but that's a whole nother conversation) so that this isn't a concern, or a very short list of folks so that publishing can't happen by mistake or without enough communication.

[joyeecheung]

@JasonEtco Yes, nodejs/TSC#406 (comment) mentioned semantic-release, that seems like a good fit.

[MM422]

"automation-collaborators" structure is actually a great idea 👏 . I believe this structure will protect our collaboration from mistakes.

[maclover7]

I like the idea of having wider commit access to nodejs/automation, and then a smaller subgroup that will handle npm releases. I'm not sure if it's a good idea to have separate teams for each tool, since the teams would probably be small-ish, and there would also probably be a lot of overlap between the tools.

[joyeecheung]

So on a second thought, this is what I am leaning towards right now:

• nodejs/automation: people to ping for automation related issues
  • nodejs/automation-collaborators: has write access to all repos/the monorepo
  • nodejs/automation-admins: has admin access of all repos/the monorepo (can add new collaborators)

[Tiriel]

@joyeecheung I'm definitely with you on the last one

[joyeecheung]

So given the responses in #8 (comment), I think we can try out the subteam structure first. I have created the two subteams, will open a PR to explain it in the readme & see if there are any more opinions on this later.