doc: document the @nodejs/doc-kit subteam

[ovflowd]

We created the @nodejs/doc-kit team on GitHub so contributors to nodejs/doc-kit can be onboarded without handing them the whole Web Team surface, and the docs here never caught up. This PR documents it:

• PERMISSIONS.md: new @nodejs/doc-kit column. The only non-empty cell is Write on nodejs/doc-kit, everything else, including every external service, is -
• GOVERNANCE.md: new section covering the team, its scope, and its nomination process, which mirrors @nodejs/web-infra
• MEMBERS.md: new section, seeded with the current members of the GitHub team
• onboarding/doc-kit.md: onboarding checklist, deliberately much shorter than web-infra's
• README.md: two subteams becomes three

The scope is intentionally narrow: Write on nodejs/doc-kit and nothing else. No publishing access for now, so no 1Password vault, no Vercel, no npm scope ownership, those stay with @nodejs/web-infra. Releases still go out through the repo's automated workflow via npm trusted publishing, so this doesn't block anyone from cutting one.

Heads up that touching GOVERNANCE.md pulls in @nodejs/tsc via CODEOWNERS. Happy to split that file into its own PR if y'all would rather land the rest first.

Refs: nodejs/admin#1091

[bmuenzenmeyer]

the doc-kit team shouldn't be maintain, right?

Suggested change

	| **[nodejs/doc-kit][]** | Read | - | Write | Maintain | Maintain | Admin | |
	| **[nodejs/doc-kit][]** | Read | - | Write | Write | Maintain | Admin | |

[ovflowd]

I was wondering if they should be maintain on doc-kit and maybe write on nodejs.org/learn as they're downstream consumers of doc-kit. But also completely fine if they only get write on doc-kit and nothing else.

[bmuenzenmeyer]

i feel strongly that a new member should not be able to add another new person day one

[ovflowd]

what? maintain doesn't give you permissions to add people.

[ovflowd]

Sorry what are you referring to? Are you referring to "team" maintain permissions? I'm referring to "repository" maintain permissions. "maintain" gives a few extra options on a repo

[bmuenzenmeyer]

re-reading https://docs.github.com/en/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository-roles-for-an-organization#permissions-for-each-role - i was mistaken. looking at all those permissions, maintain is still too high to me and this would be incongruent with our model for the website itself

edit: screenshot showing my perceived disconnect

[ovflowd]

All good! I was just confused and wanted to ensure we're talking about the same thing

[bmuenzenmeyer]

your point about learn is a good one to consider. without write we'd expect them to fork and pr. i guess it depends on what we expect a doc-kit maintainer to do day to day. that's how they'd have to interact with core.... so maybe its fine

[ovflowd]

looking at all those permissions, maintain is still too high to me and this would be incongruent with our model for the website itself

Yeah, that's fair. Although, the idea behind here is different. Because doc-kit team is a team dedicated to maintain the doc-kit project, including its packages. Whereas the Website Team is responsible for writing the website, but the maintainership of the website is part of the Web Infra team.

I guess we can leave with Write permissions, or solidify so that Website team has maintain on the Website, and doc-kit team has Maintain on doc-kit.

your point about learn is a good one to consider. without write we'd expect them to fork and pr. i guess it depends on what we expect a doc-kit maintainer to do day to day. that's how they'd have to interact with core.... so maybe its fine

The thing is that the UI components doc-kit uses are on the Website repo, so unsure if doc-kit team would need write on website. I guess for learn all they'd do there would be to update doc-kit packages... But I believe dependabot already does that so they don't really need Write permissions there.

TL;DR

• Write on Website, None on Learn, Write on Doc-Kit