Repository navigation
Proposal: Core subsystem Code Owner teams #1853
Description
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/de-value non-Core contribution
- lower barriers to entry
- increase agility (more reviewers, more landers, etc)
- increase engagement
Proposal
Collaborator
- 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):
- unchanged: via existing Collaborator (or TSC—who are Collaborators)
- barrier to entry should be high
- contributions across multiple teams (may be waived for extensive, multi-year tenure with the project)
Explicit criteria punted to a subsequent proposal
minimum of 1 year of consistent contributionsupport minimum: 10% of Collaboratorsmust be explicit, eg 👍 or+1in a comment
(Team) Member
- approve or block PRs to their subsystem (eg
node:test) and votes within their team (eg a nomination)
Context on teams (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 such as Remove Inactive Users admin#1030)
- Administered by lead(s)/chair(s) (
adminrole on team repo,maintainerof the GH team, etc)
- Initial block resolution starts within the team; recommended approach:
- Team votes
- Overturned
- Escalate to TSC
- Team votes
Nominations
- barrier to entry should be moderately low
- demonstrates (to a lesser extent) qualities of a Collaborator
- managed by the team
- existing team members may vote on both team member and team maintainer nominations
Explicit criteria punted to a subsequent proposal
minimum of 3 months of consistent contributionSupport minimum: simple majority
Quorum: ⅔
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 posting in nodejs/admin:
- a non-Collaborator
- TSC approves a request by an aspiring organisation member to join
- A TSC member acts as team maintainer to oversee until the team is sufficiently populated
- TSC approves a request by an aspiring organisation member to join
- a Collaborator
- (after 1 week) adds themselves to the GH team (no approval required as there's no-one to vote)
- A TSC member adds them to the team's
maintainersubteam andadminto team's repo.
Core
The nodejs/node repository
- Subsystems are code-owned by a respective team (eg
node:testis code-owned by the@nodejs/core/test-runnerteam). @nodejs/core/collaboratorshas codebase-wide code-ownership- At least 1 code owner approval is required to land a relevant PR
- When there is no owning team, a Collaborator (exercising the aforementioned caution) or TSC member provides the code-owner approval
mainbranch is protected againstwrite(a PR is required) except for TSC &@nodejs/core/releasers- includes manually landing a PR
cc @nodejs/collaborators @nodejs/tsc
jasnellI'd prefer us to simplify things here significantly.
The key issues that I see are: (a) new contributor nominations and (b) reviews from folks that are adequately knowledgeable of relevant subsystems.
Both can be addressed by increasing focusing on teams.
Renaming things is secondary and ceremonial without actually solving any of the actual issues.
The most I'd like to see us do is this:
- Assign every subsystem an owning team
- Any change to that subsystem must be approved by at least one member of the owning team (any other collaborator can also approve additionally)
- All new collaborator nominations originate from teams. That is, a member of team X nominates a new collaborator to join team…
Activity
Trott commentedon Apr 29, 2026
Does this mean an approval from
@nodejs/core/maintainersis enough as they have codebase-wide code-ownership? Or does that mean a change to thednsmodule must be approved by a member of the DNS team?(Admittedly, I skipped right to
#Coreso maybe my question is answered already in there somewhere.)JakobJingleheimer commentedon Apr 29, 2026
Indeed it is 😜
It's basically the gentleman's agreement we have now: A Maintainer would be expected to generally defer to the team for the owner approvals and blocks (they can of course voice their opinions and concerns, which should be respected). A maintainer could do, especially when the team is not so active (or doesn't exist).
Qard commentedon Apr 29, 2026
Does this imply the "collaborator summit" should be renamed "maintainer summit" to align? I would argue we might want to explicit keep the collaborator label as an umbrella term for all contributors such that the summits can be communicated clearly as a thing that is not just for people with the maintainer bit. That'd align more cleanly with the GitHub sense of what collaborator means, which is good. We'd want some clear documentation somewhere to differentiate these terms though so as to not confuse people.
JakobJingleheimer commentedon Apr 29, 2026
No because members would be explicitly in now. If anything, it would be "members summit".
But collaborator summit is a great name for it. That ain't broke.
Exactly. "collaborator summit" may even be even more fitting after this because non-Core Collaborators are actually already welcome (but that's little-known currently).
joyeecheung commentedon Apr 29, 2026
Off topic: it's not collaborator summit. It's collaboration summit, and we did try to correct this term everywhere e.g. nodejs/nodejs.org#6654
And no, you don't even need to be a member to come. It's unrelated to any membership. You don't even need to be a contributor (I wasn't a contributor at my first summit, and IIRC every summit has had non-contributors). Whatever requirement there is mostly about being a real person who won't vandalise whatever venue we borrow.
richardlau commentedon Apr 29, 2026
Qard commentedon Apr 29, 2026
Yep, I'm just thinking this is a good opportunity to also refine our communication around the collab summits to make it clearer that it is open to a broader base of people. We've long had a few non-core folks attending, but we never really said anything official about that as far as I'm aware. Just seemed to me like keeping the "collaborator" label in a way which aligns with how GitHub defines it would be useful for that purpose. 🙂
Anyway, I think that is a bit of an aside from the core of the topic, and I don't want to veer the conversation too much off-course.
joyeecheung commentedon Apr 29, 2026
It's about as official as what the website says https://nodejs.org/en/about/get-involved/collab-summit
joyeecheung commentedon Apr 29, 2026
Personally I don't think maintainer is a good word. For me being a maintainer means "actively sharing the maintenance burden that most people won't volunteer to take on", this can't be said about most collaborators or even many TSCs. IMO it's strange to name someone a "maintainer" even though they aren't taking over much burden. It isn't healthy for a project with 100+ maintainers but most of them don't show up very frequently to share the burden and people still complain about the burden - take the extreme lack of care of the CI, for example. I would be okay with creating this role for those who really take on chores that nobody likes to do, such as gardening the CI, though.
Qard commentedon Apr 29, 2026
Fair point. I feel like "contributor" better matches what they're actually doing. Difficult to figure out appropriate terminology for these things when so many of these terms are so loaded with external context. As always, naming things is hard. 😅
avivkeller commentedon Apr 29, 2026
At Apache, they use "Committer"?
JakobJingleheimer commentedon Apr 29, 2026
I think that's how it should be, which is why it's a good name. I think maintainer sharing the burden is the spirit of this role.
JakobJingleheimer commentedon Apr 29, 2026
That sounds more akin to the member role.
A maintainer has broad powers; they should be using them, otherwise they don't need them.
Qard commentedon Apr 29, 2026
That is a bit too tied to the act of committing code though. There are lots of valuable contributions beyond just committing code to the repo and I'd like whatever naming we choose to communicate that effectively.
joyeecheung commentedon Apr 30, 2026
I think that should be based on objective metrics, not subjective evaluations like nominations. If the current collaborator system isn't good enough in splitting the load, a similar system won't do either IMO. Also the proposal isn't very clear about how that migration is supposed to happen, it currently only looks like renaming the group + off board some people from this group using a higher bar in the process. Then maybe just raise the bar/update the script that finds inactive collaborator? The renaming seems mostly ceremonial and only introduce churns/overheads.
25 remaining items
jasnell commentedon May 6, 2026
I'd prefer us to simplify things here significantly.
The key issues that I see are: (a) new contributor nominations and (b) reviews from folks that are adequately knowledgeable of relevant subsystems.
Both can be addressed by increasing focusing on teams.
Renaming things is secondary and ceremonial without actually solving any of the actual issues.
The most I'd like to see us do is this:
mainare TSC members and release WG members. Everyone else goes through the automated tooling.joyeecheung commentedon May 6, 2026
As I mentioned in the collab summit, I don't think this makes sense. We cannot assume all subsystem have active contributors, and most likely many subsystems don't have anyone who are willing to be responsible for it or or any one doing any kind of onboarding/offboarding (this coordination is actually work that gets overlooked a lot and seriously lacking in the organization). Being interested in occasional contribution and being interested in being an owner that will answer for a subsystem are two completely different things, and the latter will be an enormous ask for volunteers. Some subsystems have the luck to have some volunteers who would take care of them, but many subsystems don't and their existing team are full of people who will never respond to pings. It will be too much work to identify active reviewers for all subsystems - who's actually going to do this coordination work? If the TSC is actually capable of this we wouldn't have so many subsystem teams full of inactive members that will never respond to pings because they have moved on from the project in the first place.
Instead of "assigning subsystem to teams" (in general assignment is awkward in a volunteer-based model), I's suggest we just ask existing members in the organization to form new teams and sign themselves up as reviewers for certain subsystems. For subsystems without volunteering reviewers, just let it be - it's in the custody of existing collaborators, just as before. And we can set up some rules to make sure the new teams take care of gardening themselves e.g. every couple of months, all members must formally confirm they still intend to be an owner. If they don't even show up to confirm they want to stay, they will be automatically removed. This solves the current issue with have with almost every existing subsystem team full of inactive members.
jasnell commentedon May 7, 2026
@joyeecheung
That doesn't mean we can't have a team for it. A team with no members falls back to the large collaborator base. It's more of a logical organizing principle.
joyeecheung commentedon May 7, 2026
Why do we need the ceremony of setting up many empty teams? What happens if a team only has one or two member that disappear? I think in addition to not forcing a team upon every subsystem which is not practical, we should also enforce a minimum number of active members in a team for a team to be valid. I think many existing teams actually are practically empty (if we consider how often the members actually do submit changes/reviews/comment in their subsystems) and we are just reinventing the same structure that are prone to this ghost team problem again. The "every piece of code must have someone actively answering for it" philosophy just isn't compatible with a volunteer-driven project IMO. The compatible one should be "if more volunteers want to help, as long as some other volunteers help maintain a trust network with them, let them help".
JakobJingleheimer commentedon Jun 14, 2026
Wuuut. No, I'm not saying that at all. All new org members would expressly be onboarded by TSC:
The TSC would continue to handle adding new members to the org (and also the onboarding call). Collaborators don't have access to do this anyway since it requires Org Admin permissions (which only the TSC have?).
👍 the proposal currently says this almost verbatim…
👍 I think it should also include the ability for those subsystem teams to nominate
"Approved by the TSC" this is too oligarchical. If a TSC member objects, they can already 👎 to trigger a similar process. So this is already effectively the case but without the "TSC overloads" implication.
Unless I missed it somewhere (sorry if I did), I think this was based on a brand new idea you had in your head that you only now just shared? (Where Collaborator nominations are approved by TSC instead of existing Collaborators) My comment about "unengaged and unfamiliar" people is related to the status-quo, where Collaborators typically do not work outside of their subsystem teams (so they would be unfamiliar with nominees from other subsystem teams) and unengaged meaning almost no-one currently participates in nominations because of the toxic spiral they often become.
JakobJingleheimer commentedon Jun 14, 2026
This sounds good to me. I think this is already covered in the current proposal, but the current proposal has additional things, and you'd like those removed or punted, right?
JakobJingleheimer commentedon Jun 14, 2026
I think this is not orthogonal? I think it wouldn't be ceremony to create an empty team because we hope will it be used at some point, and it also enables us to easily keep track.
Having a minimum number of team members does kinda make sense from a trust standpoint, but creates logistical problems when starting or resurrecting a dead team (e.g. if the minimum is 3 and fewer than that are interested initially, then they're stuck searching for more people, being unable to do anything in the meantime).
I think/hope the new governance will address this by creating more engagement. The most active teams we have are ones that operate the way this proposal outlines (which is why I included it).
Also, I've seen that less tenured members are often intimidated; that creates a bit of a double-edged sword in that they're cautious, refraining from doing things they technically can but shouldn't do, but also makes them overly cautious and don't do things we'd want them to do. This tells them expressly "this is okay; please do do this".
watilde commentedon Jun 14, 2026
I really support the goal of making responsibilities clearer, but I’d love to share a small concern regarding our community culture and sustainability, rather than just the code structure itself.
1. The Hidden Cost of "Supervision"
Even if we divide the ownership into clean subsystems, our codebase is interconnected. Overlaps, conflicts, and gray areas will inevitably pop up. When they do, we will naturally need someone to step in as a "Supervisor" or "Decision Maker" to untangle them.
My worry is that this will accidentally centralize a new kind of emotional load onto our core active maintainers (like the TSC). Instead of reducing burnout, it might just shift the burden from "reviewing code" to "managing organizational friction."
2. Preserving Our Culture of Trust
To me, the greatest strength of Node.js has always been its friendly, high-trust atmosphere. When we formalize roles into strict titles like "Code Owner" or "Maintainer," the psychological dynamic can subtly change. I really want to avoid a situation where people start feeling protective of their "silos" or where the warm, collaborative spirit turns a bit too formal or tense.
3. Defining a Reversible Experiment
If we decide to try this out, I highly recommend treating it as a reversible experiment with clear, pre-defined success and exit criteria. Before we roll it out, we should agree on:
I just want to make sure that as we optimize our governance, we keep safeguarding the wonderful culture that brought us all here in the first place.
JakobJingleheimer commentedon Jun 14, 2026
Thanks for raising the concerns 🙂
I can't think of something like this happening before. Can you think of a particular example of something similar within node core? I'm asking because I think this won't be an actual problem we need to account for, or if it does occur, it'll be rare enough and low-severity enough that we can safely cross that bridge if we get to it.
I expect if this does happen, this subsystem ownership would actually help: we'd have recognised & surfaced SMEs, so if an SME says "this would have an unacceptable impact on subsystem X" that's a pretty authoritative "don't". If their argument is invalid or unfounded (and they won't budge), yeah, that gets bumped to the TSC; that's what already happens now though (and I think it generally works?).
This is already the case. Is this bad? I think it's only bad if it makes someone unreasonable like "nobody else can touch my baby".
💯👍
Next-10 will continue to monitor this; if we do see that starting to happen, we'll course-correct.
💯👍 Next-10 will track (that was always the plan 😉)
Hmm, that's a good question. I had been planning to continue to ask and monitor the questions in the collab survey that confirmed & quantified the current problems. Is that sufficient?
joyeecheung commentedon Jun 14, 2026
Empty team just means nobody can approve a subsystem unless they sign themselves up to be an owner, which is a lot to ask than occasional contribution. I think assignments and ownership are just philosophically incompatible with a volunteer-run project, we need to admit that contributors generally don't have that much time to spare for Node.js, and a new structure should enable us to use better what fractional time people do have to push things forward, not bottleneck more things on time that contributors already can't spare all that much for the project or introduce organisational ceremony that eats even more volunteer time.
The logistical problem only exists if we "assign every subsystem a team". It's self inflicted. If we keep collaborators as a base and just add some teams on top for select subsystems, then not having any team assigned to a subsystem is fine. If there are more than 3 then there are additional reviewers; if there are none then so be it and let collaborators review them as before.
From what I know team become ghosts because contributing to Node.js just stops being part of what people prioritise, either because of changes at work or changes in life. I don't think changing structure is going to change the fact that contribution is voluntary and in the end most contributors will move on from this project, what compensates the loss of contributors is having new contributors and empowering them to do more things, not asking for more free labour from volunteers who have less time for Node.js because of life/work.
JakobJingleheimer commentedon Jun 15, 2026
James (and I think Matteo too?) suggested having the TSC handle those (because the TSC are often the most active, tenured, and broadly contextually aware contributors). The rationale was that a non-SME likely doesn't have sufficient context to approve the PR (and without that, it shouldn't be approved).
Many successful OSS projects operate this way (assignment and ownership), so that can't be true.
I think we do all recognise that?
I think we all generally agree on that too?
It's tricky because we need a balance: empower trusted contributors but also have sufficient guardrails to avoid a wild-west. I certainly loathe stupid, arbitrary "just get out of my way" rules. I thiiink this is not that because there is a clear path to "get it out of the way".
I think that's mostly the reason; another reason is people getting fed-up with bureaucratic issues.
I think the change in structure will help (but not resolve) that "another reason"; but the main target, I believe, will be "having new contributors and empowering them to do more things". That's what this is trying to accomplish—and I think it will at least partially.
joyeecheung commentedon Jun 15, 2026
Even the current core meta team already has 50+ sub teams, I don't think asking the volunteers on the TSC to maintain 50+ owner teams is going to be sustainable if the proposal insists that all subsystems must have an owner team. The TSC is generally very overloaded to act as a bottleneck (take a look at the average issue handling speed in the admin repo for example). The owrnship proposal IMO overall underestimates how much free labour it's asking from contributors.
I would say "success" is very subjective, and it's questionable whether these projects are successful because of the flaws of these structures or despite of. From outside Node.js, many would also say Node.js is successful and therefore can make assumptions that the existing structure that we have therefore is successful or preferable compared to theirs because they know their internal struggles better than us. If we view it with that lense then we don't even need any changes to our current structure.
JakobJingleheimer commentedon Jun 15, 2026
Okay, thriving.
[-]Proposal: Core subsystem Code Owner teams + Collaborator → Maintainer[/-][+]Proposal: Core subsystem Code Owner teams[/+]