Session Proposal: Node.js collaboratorship

[JakobJingleheimer]

Proposal

Let's kick the hornet's nest 😬

Collaboratorship is currently a conflation of GitHub permissions, "citizenship", and trust. This conflation often creates significant friction (in the better cases) during nominations, and sets an inconsistent bar and level of expectations.

Topic of the session

Type of the session

• Collaborate
• Workshop
• Talk

Estimated duration of the session

2 hours ideally broken across 2 sessions, perhaps days (I anticipate contention, and also needing time for sidebars etc).

Date and Time of the session

Level

• Beginner
• Intermediate
• Advanced

Pre-requisite knowledge

We've had 1 new collaborator in the past year 😳

Describe the session

• Break down project needs
• Outline what we have now
• Discuss problems with the status quo
• Discuss what we need to achieve
• Discussion potential solution(s)

Session facilitator(s), Github handle(s) and timezone(s)

• @JakobJingleheimer (on location - London BT)

Meeting notes and Virtual Meeting Link

Follow-up / Set-up sessions (if any)

Additional context (optional)

---

[joyeecheung]

For remote attendants: the draft agenda is in https://docs.google.com/spreadsheets/d/1FjBayj38Bu3FAUoZSi8LCY0NrkyXaTt4h9zUIT7ei2Y/edit?usp=sharing (it's not final, this session is currently planned to be 14:45 London time on April 14 & 15). If you have any comments, it would be easier to coordinate in the #collab-summit-london-2026 slack channel

[JakobJingleheimer]

Outcome: working plan / path forward

Repos

Cross-concern repos

(Like nodejs/core and nodejs/learn)

• Leverage Code Owners
• Each subsystem is maintained by a subteam eg @nodejs/core/test-runner
  • Each subsystem is code-owned by its team
  • At least 1 code owner approval is required to land a relevant PR
  • When there is no team, a TSC member provides the code-owner approval
• main branch is protected against write (requires PR) except by TSC & @nodejs/core/releasers
  • includes manually landing a PR

Team repos

• Maintained by a team (eg nodejs/userland-migrations ← @nodejs/userland-migrations).
• write via base team (eg @nodejs/userland-migrations).
• maintain via subteam (eg @nodejs/userland-migrations/maintainers).
• main branch protected against write (requires PR) except by maintainer (and TSC)

Teams

• 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)
• Initial block resolution starts within the team; recommended approach:
  • Team votes
    • Overturned
    • Escalate to TSC
• Administered by a lead/chair (admin role on team repo, maintainer of the GH team, etc)

Quorum: ⅔

Nominations

• Managed by the team
• Members may vote on both member and maintainer nominations.
• Support minimum: simple majority

Member

• barrier to entry should be low
• minimum of 3 months of consistent contribution

The team maintainers handle new member onboarding.

Maintainer

• barrier to entry should be somewhat high
• minimum of 3 months on the team

Empty teams

An empty team can be resurrected by:

• TSC approving a request by an aspiring collaborator 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.

Node.js "Collaborator"

• "member" of the Node.js organisation
• member of specific team(s)

New member to Node.js org

1. A team maintainer tags @nodejs/tsc on the team repo's nomination (once approved) requesting the user be added.
2. The actioning TSC member sends the invite and comments on the nomination that the invite has been sent.
3. New member responds to confirm.

Node.js "Maintainer"

• Formerly what was called a "collaborator" (most collaborators just become maintainers).
• Org-wide permissions
  • write on repos (exceptions for special repos, eg nodejs/release owned by a Working Group)
• Expected to exercise caution when operating outside their expertise

Nominations

Via existing Maintainer or TSC

• barrier to entry should be moderately high
• minimum of 1 year of consistent contribution (1–2 gaps of up to 2 months allowed but subtracted from the 1 year)
• contributions across multiple teams (may be waived for extensive, multi-year tenure with the project)
• Nominator has a responsibility to make a good case, citing specific examples; the idea is this should make it easy to say "yes"
  • Examples must be specific highlights with direct link(s) (eg X demonstrates trust, Y demonstrates good judgement, Z demonstrates stewardship, etc for each/most criteria); nominator commentary is encouraged
    • objections claiming material is not demonstrative must provide a "this is what good looks like" example and should explain how the providing material does not meet it
  • more generic examples/links may also be provided, for example to demonstrate breadth/volume
• must tag @nodejs/maintainers on both private and public nomination (both private & public are required)
  • concerns & objections should be made on the private nomination
• support minimum: 10% of maintainers
  • must be explicit, eg 👍 or +1 in a comment

Nominations (general)

• must have sufficient member support
• concerns must be resolved; an unresolved concern is effectively contention
• must not be contended; a downvote must be accompanied with an explanation citing specific concern(s) paired with conditions for addressing the concern, where applicable.

A TSC member handles new Maintainer onboarding.

---

cc (the people who spoke during the sessions) @aduh95 @BethGriggs @bnb @BridgeAR @jasnell @joyeecheung @mcollina @ovflowd @RafaelGSS @wesleytodd

I think this captures the consensus reached (and fills in the gaps). If not, please comment back so I can correct it (I think using a diff code-block would be most helpful). We don't need to worry about word-smithing here (this just needs to capture the spirit—a PR will update the various docs/guidelines, and that's where we can smith words).

If this does accurately capture the consensus reached, I think next steps would be:

• Set up inactive member tooling; I spoke with Aviv, and they're willing to create the inactive member tooling.
• PR to update docs/guides (I'll handle)
• Handle the administrative tasks to apply the above; I'm happy to do this too (I think I currently have sufficient permissions to do some but not all, in which case I would ask to temporarily be granted heightened permissions).
  • There's some trick, non-obvious things needed to setting up the teams properly so permissions inherit and override each other; I've done for multiple teams, so I'm familiar.

[joyeecheung]

I didn't have time to read all the points but I don't recall any consensus on an org-wide maintainer status that has write access to all repos. Personally I am -1 and I think we should go with the opposite direction - we can make TSC a fallback for repositories that are no longer maintained, but all maintained repositories should be self-governed separately as much as possible. For example even though I have org-wide permission for almost a decade, whenever I open a PR or review something in repository that I do not help maintain e.g undici I always delegate permissions/approvals from actual maintainers of that repository, I think it's important to keep boundaries and do not overreach, especially as we incorporate more external projects in the organization and it becomes unrealistic for someone to be knowledgable about all of them.

[JakobJingleheimer]

an org-wide maintainer status that has write access to all repos

I need to re-watch the recording; which specific permission was possibly not write (it may have been triage).

I think […] we can make TSC a fallback for repositories that are no longer maintained, but all maintained repositories should be self-governed separately as much as possible

That's exactly what this advocates/outlines 🙂 (or at least, that was the intent)

[joyeecheung]

If this does accurately capture the consensus reached, I think next steps would be:

For formal discussions, this needs to be discussed in nodejs/admin or nodejs/tsc, and for the scale of things this might deserve pining nodejs/members and nodejs/collaborators. No org-wide consensus should be considered reached in a meeting with just a small subset of the contributors, especially not at the summit - we have always tried very hard to prevent the summit from being an exclusive decision making club for those who can afford to join.

[JakobJingleheimer]

Okay! Happy to move this there then. Thanks!

PS By "consensus reached" I meant "this is where the summit session settled". I wanted to get that squared away before bring it forward (and potentially misrepresenting what came out of the summit session).

[joyeecheung]

Thanks for the clarification - though I'd caution on using any wording regarding "consensus at the summit" when trying to bring a point in the discussions. Again we need to prevent the misunderstanding that the vibes in the room of a summit holds any more weight than regular GitHub discussions when it comes to decision making. Summit discussions are mostly for testing the temperatures with a sample, and in rare cases where the group that can decide on a specific matter is already represented enough in the summit decisions can be made but it still holds no more weight than any fully virtual Zoom meetings. In cases where fully virtual Zoom meetings aren't enough for pushing any proposals, summits aren't enough either.

e.g. https://github.com/nodejs/node/blob/main/GOVERNANCE.md#tsc-meetings

All discussions made during meetings are considered provisional, receiving no objections from folks at the TSC meeting to take an action is not equivalent to the TSC endorsing that action.