Proposal: Core subsystem Code Owner teams + Collaborator → Maintainer

I've tried to distill the great feedback from the node summit session a couple weeks ago. It does end up being somewhat surprisingly long because of what-ifs and what-abouts; the TLDR is found #Core at the bottom.

Motivations

• un-devalue non-Core contribution
• lower barriers to entry
• increase agility

Proposal

Collaborator → Maintainer

The "Collaborator" name is dropped 😢 It means something completely different in GitHub, and it's not common within the ecosystem.

"Maintainer" largely replaces "Collaborator".

• Most Collaborators just become Maintainers
• Expected to exercise caution when operating outside their teams

Nominations

Inherits the current Collaborator nomination policy with some notable points of clarification (on things that are currently vague):

• via existing Maintainer or TSC
• barrier to entry should be moderately high
• minimum of 1 year of consistent contribution
• contributions across multiple teams (may be waived for extensive, multi-year tenure with the project)
• support minimum: 10% of Maintainers
  • must be explicit, eg 👍 or +1 in a comment

(Team) Member

• approve or block PRs within their purview (eg a subsystem like node:test)
• write permission on their respective repository/ies
  • this enables a member to trigger CI (this is possibly changeable if we want)

Nominations

• barrier to entry should be moderately low
  • minimum of 3 months of consistent contribution
  • demonstrates (to a lesser extent) qualities of a Maintainer
• managed by the team
• existing team members may vote on both team member and team maintainer nominations.
• Support minimum: simple majority

Team member onboarding is handled by a team maintainer.

Organisation member onboarding is handled by a TSC member.

Empty teams

An empty team can be resurrected by:

• TSC approving a request by an aspiring member to join
  • A TSC member acts as team maintainer to oversee until the team is sufficiently populated
• a Maintainer
  1. posting in nodejs/admin to signal intent
  2. (after 1 week) adds themselves to the GH team (no approval required as there's no-one to vote)
  3. A TSC member adds them to the team's maintainer subteam and admin to team's repo.

Context on teams

[!IMPORTANT]
This is not new.

• Largely self-managing
  • Can establish own policies extending general policy
  • Handle own membership:
    • requests to join
    • nominating new members
    • expelling members
    • pruning inactive members (assisted/informed by an automation)
  • Administered by lead(s)/chair(s) (admin role on team repo, maintainer of the GH team, etc)
• Initial block resolution starts within the team; recommended approach:
  • Team votes
    • Overturned
    • Escalate to TSC

Quorum: ⅔

Core

The nodejs/node repository

• Subsystems are code-owned by a respective team (eg node:test is code-owned by the @nodejs/core/test-runner team).
• @nodejs/core/maintainers has codebase-wide code-ownership
• At least 1 code owner approval is required to land a relevant PR
  • When there is no owning team, a Maintainer or TSC member provides the code-owner approval
• main branch is protected against write (a PR is requires) except for TSC & @nodejs/core/releasers
  • includes manually landing a PR

cc @nodejs/collaborators @nodejs/tsc

Start with the Collaborator → Maintainer, Team Member, and Core sections, then review the linked Node.js summit discussion and the mentioned nodejs/admin and nodejs/node repositories. Done requires TSC agreement on the governance model and documented team, ownership, nomination, and branch-protection rules. The issue names no implementation files or tests.