Proposal: Core subsystem Code Owner teams

[JakobJingleheimer]

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

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):

• 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 contribution
• support minimum: 10% of Collaborators
  • must be explicit, eg 👍 or +1 in 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) (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

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 contribution
• Support 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:

• 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 Collaborator
  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.

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/collaborators 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 Collaborator or TSC member provides the code-owner approval
• main branch is protected against write (a PR is required) except for TSC & @nodejs/core/releasers
  • includes manually landing a PR

cc @nodejs/collaborators @nodejs/tsc

[Trott]

At least 1 code owner approval is required to land a relevant PR

Does this mean an approval from @nodejs/core/maintainers is enough as they have codebase-wide code-ownership? Or does that mean a change to the dns module must be approved by a member of the DNS team?

(Admittedly, I skipped right to #Core so maybe my question is answered already in there somewhere.)

[JakobJingleheimer]

(Admittedly, I skipped right to #Core so maybe my question is answered already in there somewhere.)

Indeed it is 😜

Does this mean an approval from @nodejs/core/maintainers is enough as they have codebase-wide code-ownership? Or does that mean a change to the dns module must be approved by a member of the DNS team?

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]

"Maintainer" largely replaces "Collaborator".

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]

Does this imply the "collaborator summit" should be renamed "maintainer summit" to align?

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.

would argue we might want to explicit keep the collaborator label as an umbrella term for all contributors

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]

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]

They're called Node.js Collaboration Summit (not Collaborator Summit). I think it was renamed a few summits ago.

At least for the ones I've attended in person there has always been several non-collaborators in attendance.

[Qard]

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]

Node.js's Collaboration Summit is an un-conference for bringing current and potential contributors together to discuss Node.js with lively collaboration, education, and knowledge sharing.

It's about as official as what the website says https://nodejs.org/en/about/get-involved/collab-summit

[joyeecheung]

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]

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]

At Apache, they use "Committer"?

[JakobJingleheimer]

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

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]

At Apache, they use "Committer"?

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]

At Apache, they use "Committer"?

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]

I think maintainer sharing the burden is the spirit of this role.

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.