Proposal: allow for subsystem collaborators in nodejs/node (refinement of #1853)

[mcollina]

A scoped-down version of nodejs/TSC#1853 that touches only the nodejs/node repository. The two-approval landing rule is preserved as-is.

Problem

Every Collaborator on nodejs/node has codebase-wide approval rights (governance, code reviews). Subsystem ownership is only a social convention via Who to CC.

That single tier stalls nominations: contributors deeply competent in one subsystem (e.g. lib/internal/test_runner, lib/crypto, lib/fs.js) wait — sometimes for a year — to demonstrate breadth they may never need, because the only available bit grants binding review everywhere.

There is no rung between an external contributor and a full Collaborator. This
proposal adds that rung.

Proposal

1. Subsystem teams as code owners (advisory)

Materialise the Who to CC mapping into a CODEOWNERS file. Used to auto-request reviews and document ownership in machine-readable form. Not a merge gate — the two-approval rule is unchanged and no code-owner approval requirement is layered on top.

2. @nodejs/core/<subsystem> membership as a real tier

Membership in a subsystem team — e.g. @nodejs/core/test-runner, mirroring @nodejs/test_runner —
confers, for that team's paths only:

• Binding approval that counts toward the two-approval threshold.
• CI start/resume rights (Testing and CI).
• Block authority under objections.

It does not confer binding approval outside those paths, direct push to main, or membership in @nodejs/core/maintainers.

Concretely: a PR touching only lib/internal/test_runner can land with two approvals from any mix of @nodejs/core/test-runner Team Members and @nodejs/core/maintainers. A PR touching crypto cannot be landed by two test-runner Team Members — outside their paths, their reviews are non-binding.

Branch protection

main is protected against direct write for everyone except @nodejs/tsc and @nodejs/core/releasers. The manual landing flow]technical-howto now goes through a PR; the commit queue is unaffected.

Nominations

Use the existing Collaborator nomination process unchanged. The only delta is the bar: the Ideal Nominees guidance is evaluated scoped to the team's paths — "trusted to give binding review on node:test PRs?" rather than "ready to give binding review across all of core?".

Promotion from a subsystem team to @nodejs/core/maintainers uses the same nomination process against the existing codebase-wide bar; a subsystem track record is evidence, not a substitute.

Rationale

The current stall is not "is this person good?" — it is "does competence in one area license binding approval everywhere?". The single tier forces reviewers to answer the second question before granting any binding review at all, so they answer it conservatively.

Splitting the tier separates the two questions without changing the
nomination mechanics:

1. Binding review where they actually contribute? — scoped bar, existing
   process.
2. Binding review across all of core? — codebase-wide bar, existing
   process, with the subsystem track record as evidence.

For contributors, this replaces a multi-year all-or-nothing wait with a visible incremental path. For nomination reviewers, "not ready to approve a V8 update" stops blocking someone whose work is in lib/internal/test_runner. Every existing safeguard — two approvals, wait time, CI, objections, TSC escalation — is preserved.

Out of scope

From nodejs/TSC#1853, deliberately excluded here:

• Renaming "Collaborator" → "Maintainer".
• Anything outside nodejs/node (org-wide member/triager tiers, TSC charter).
• Changes to the Collaborator nomination process mechanics — only the bar is scoped for the new tier.
• Changes to the two-approval rule. No code-owner gate is added.

Migration

1. Author CODEOWNERS from the Who to CC table. Advisory only.
2. Create @nodejs/core/maintainers, seeded from @nodejs/collaborators. Reuse existing subsystem teams.
3. Update collaborator-guide.md and GOVERNANCE.md for the new tier and the scoped nomination bar (process unchanged).
4. Protect main against direct write outside @nodejs/tsc and @nodejs/core/releasers.
5. Open subsystem-team nominations.

Steps 1–3 are reversible config/docs. Step 4 is the only merge-flow change.

[JakobJingleheimer]

Thanks for trying to move something forward.

However, I am a bit exasperated by what you've done here; it does not appear collaborative, it appears you have to be driving. I believe creating a mostly redundant, competing proposal is counter-productive.

I think you may have not realised #1853 is not a copy+paste of openjs-foundation/summit#486 (comment), and it incorporates your requests and suggestions.

The following are not and were never included in #1853

Out of scope

• […]
• Anything outside nodejs/node (org-wide member/triager tiers, TSC charter).
• Changes to the Collaborator nomination process mechanics — only the bar is scoped for the new tier.

My proposal also only adjusts the bar.

• Changes to the two-approval rule. No code-owner gate is added.

Your fork of my proposal in fact does add a code-owner gate—the same gate mine does.

---

The only real differences between your fork and my proposal are:

• renaming "Collaborator" → "Maintainer"
  • This was literally your idea, and it was well-liked 🤯
• nomination process for a team member
  • We explicitly discussed, and you yourself (as well as others) explicitly advocated multiple times, teams be self-managing, so I incorporated that.
  • The process in my proposal is nigh identical, merely scoped (pursuant to "teams should be self-managing").
• the specific criteria for "the bar scoped for the new tier"
  • We agreed this was needed, so I gathered feedback on what people wanted and incorporated that as a starting point.

---

I ask that you read #1853 and we collaborate on it.

[mcollina]

I actually prefer not to be driving. I read your proposal multiple times.

I've tried 3-4 times to express what I disagreed with the proposal you have assembled, and probably I wasn't able to communicate this clearly, so I tried to assemble something that I would approve.

(Note: my thinking from the collab summit has slightly changed after seeing your proposal written down, and there are plenty of things that I would not see working in practice).

On the topic, you take an org-wide perspective, while I take a nodejs/node perspective. I keep collaborator and existing terminology as-is, while adding the "maintainer" codeowner everywhere. This is simpler to implement and verify, and I hope it would solve our retention problem.

Your fork of my proposal in fact does add a code-owner gate—the same gate mine does.

No. This just requires PRs to land with two approval from two collaborators. Your requires at least one from the relevant team.

[jasnell]

@JakobJingleheimer:

... it does not appear collaborative

Multiple competing proposals is not non-collaborative. Sometimes it's the only way to easily conceptualize different approaches to solving the same problem.

[jasnell]

This is closer to what I remember being discussed in the collab summit session.