Repo and npm accesses of related projects about automation HOT 13 CLOSED

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)

from automation.

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

from automation.

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.

from automation.

@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.

from automation.

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?

from automation.

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.

from automation.

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?

from automation.

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

from automation.

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?

from automation.

@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!

from automation.

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

from automation.

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.

from automation.

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

from automation.