The state of nomination process and the meaning of being a core collaborator.

[ovflowd]

Distinguishing Contributions & Refining Node.js Core Contributor Titles

Hi folks 👋,

I’m opening this issue to address ongoing discussions around core contributor nominations and the potential for improving clarity within our group. I’ve recently observed—and participated in—some recurring friction during the nomination process, and I want to collaboratively discuss how we might refine things for the benefit of the entire project. I believe the root of the matter is a varying understanding of what being a "Core Collaborator" means, leading to disagreements on nominations, and even some unintentional miscommunication.

As was expressed during the recent nomination discussion, “We also have a problem with how this came to a head, and that’s where shit really hit the fan”. I want to ensure future nominations are productive and respectful, and I believe that a little refinement to how we define contributor groups can go a long way.

Currently, the term “Core Collaborator” seems to be used somewhat interchangeably. Sometimes it refers to fundamental individuals working within the Node.js organization, while at others it's used to indicate having write access to nodejs/node. I think this ambiguity creates confusion. As one of us noted, “…the one just clarified in the previous nomination (I requested clarification to ensure I was aligned with the group), and that’s what I based everything in this nomination upon, and that clarification is specifically what started the discourse here.” This shows we're all eager to align on clear definitions!

I propose we formally separate "Core Collaborator” into two distinct categories – acknowledging that different contributions deserve different forms of recognition and responsibility. This isn't to diminish anyone's contributions; it's to ensure each role is appropriately defined. I feel this directly addresses the concern that “…which is it?”.

Here's how I envision it:

1. Long-Term Node.js Stewards (Proposed Title: “Node.js Collaborators”) - This group would consist of trustworthy contributors dedicated to the long-term health and direction of the Node.js project. These are individuals who’ve demonstrably contributed in significant ways—through issue resolution, documentation, RFC creation/review, WG participation, triaging, etc.—making them invaluable to the organization. These individuals have a commitment to the broader Node.js mission, demonstrating “…consistent interest in moving the goals of the project forward”. We have a need for recognizing this tireless, and sometimes unseen work, as these individuals are “…closest to being the maintainers of the Node.js project.”
2. Node.js Core Committer (Proposed Title: “Node.js Committers”) – This would encompass individuals actively working on the nodejs/node repository – reviewing and merging pull requests, directly implementing features, and addressing critical bugs. This group is responsible for day-to-day maintenance and development on the core runtime.

The "Node.js Stewards" group would empower members to nominate individuals to become "Node.js Committers" (or whatever title we settle on), and also empower others within that group to also nominate. It’s a shift to recognizing that dedicated organizational support and active code maintenance have distinct focuses.

I believe this distinction would be a win-win. Both groups can be highly inclusive, offering recognition commensurate with contribution. Long-term commitment and broader project involvement are equally valuable as direct runtime contributions. These distinctions, I believe, are “essential for reducing the friction we currently face and creating a more harmonious environment”.

My goal is for everyone to feel empowered to confidently voice concerns, nominate or block others, and engage in discussions, knowing we've collectively agreed on clear definitions. Ultimately, I believe this adjustment, which some have already suggested, is what's best for the long-term health of the project, ensuring we can recognize and celebrate contributions effectively and transparently.

Let’s discuss this openly and see if we can reach a broad consensus. What thoughts do you all have?

[ovflowd]

cc @nodejs/tsc -- Also, apologies for the bit of LLM; I tried to rephrase things to sound better and easier to understand. :)

[ronag]

I worry we are making the whole thing so complicated that people will be less likely to participate. This is coming from my own feeling. Hard to keep up with everything and all the processes and guidelines already.

[BethGriggs]

+1, I'd always interpreted 'Core Collaborator' by the dictionary noun meaning:

a person who works jointly on an activity or project

Collaborators are then defined as people who collaborate with the Node.js project.

If the concern is 'we need a higher requirements to grant merge access to core', then this seems to be the way to do it. With the automation improvements and the commit queue we probably don't need every collaborator to have commit access anyway.

(I also don't think we should create a separate group called 'companion' or something for people doing wider project work - the optics of that are that they're in a lesser role in some way. Non-core code work can be just as critical for the project.)

[ovflowd]

I worry we are making the whole thing so complicated that people will be less likely to participate. This is coming from my own feeling. Hard to keep up with everything and all the processes and guidelines already.

I mean, to be honest, virtually there wouldn't more guidelines and processes, just a clear distinction and definition of what is what.

I also agree with @BethGriggs statement. Nowadays the DevEx for getting things reviewed, merged and released are way way simpler than many years ago, and this alone warrants us to at least question "is the status quo still up to date"

As much as I like the processes that got introduced over a decade ago, things change, and the chances of us having not enough contributors within core isn't a reality/fear anymore. But still I agree with @Trott that we should be lenient and permissive with giving people access to core.

[BethGriggs]

My view is that the heat that has repeatedly occurred in these discussions is going to deter participation in the project and negatively impact project members far more than some extra governance clarification or complexity would.

[jasnell]

Before we start talking about possible new policies can we first spend some time determining if we actually have a problem to solve? I'm not convinced there's even a reason to consider changing the current practices. In addition to just a basic problem statement, are there specific examples (without naming individual contributors) where the nomination process has broken down where the cause of the breakdown is the process itself as opposed to folks not understanding what the process is?

[RafaelGSS]

The fact that we've recently discussed this, with some people expressing concerns that the nomination process might be outdated or inaccurate, suggests that there is indeed a problem, right?

[jasnell]

... suggests that there is indeed a problem, right?

It suggests there is a problem, yes, but not necessarily a problem with the process itself that warrants change. It could just be that we need to spend more time making sure that new contributors understand the current process. What I'm asking for mainly is a summary of what problem needs to be solved, if any... as opposed proposed changes and solutions to problems we may not agree exist.

[BethGriggs]

I get the impression that the problems are an extension of the fact we don't have a consistent interpretation (even among the TSC) of what a collaborator 'is'. It appears some believe it's a role directly tied to experience with core code and sound technical judgement, whereas others see it as a role to represent collaboration with the project.

I mostly support @ovflowd idea to separate these so that the people who do lots of great work for the wider project don't get measured merely on the depth/complexity of core commits - which has and does happen. There were even past discussions that suggested that being a releaser shouldn't equate to being a collaborator.

(I also agree we can be relaxed when assessing the committer requirements. Similar to mentioned elsewhere, I cannot ever recall a time when technical inability was the cause of a major issue. Our automation and review process should catch any issues, and people grow when they're empowered to make mistakes and learn to fix them.)

[ovflowd]

which has and does happen. Even past discussions suggested that being a releaser shouldn't equate to being a collaborator.

I recall that... It was tough to watch.

Before we start talking about possible new policies can we first spend some time determining if we actually have a problem to solve?

I definitely do believe there is a problem, or rather, not the process itself but the unintentional problems (human factor) that keep happening due to the current process.

are there specific examples (without naming individual contributors) where the nomination process has broken down where the cause of the breakdown is the process itself as opposed to folks not understanding what the process is?

Historically, there have been many that I have witnessed. Of course, I don't recall the links now. Maybe someone can do that work for me 🙈

It could just be that we need to spend more time making sure that new contributors understand the current process.

To be honest, I don't think collaborator re-education would work at this point; it would just cause more confusion.

[srl295]

Hi folks,

The two distinctions raised make some sense. Pragmatically, what would this mean, though?

• some kind of document/process churn - updating descriptions, documents, etc
• what would/could a Steward do that a Committer wouldn't? Or is it more of a distinction in title and expectations?

[BethGriggs]

what would/could a Steward do that a Committer wouldn't? Or is it more of a distinction in title and expectations?

I'd foresee core committers always being a subset of the Node.js collaborators. The only real distinction could be write access to the repository. All collaborators should retain everything they have today, like the ability to approve/block PRs. Collaborators still have the same investment in the proejct and may represent another part of the project - their opinion should be equal.

some kind of document/process churn - updating descriptions, documents, etc

Documentation updates. Creating and populating a new GitHub subteam for committers. Any existing collaborator remains a collaborator so there's no loss of the social prestige we've built around the role over the years, either.

[srl295]

@BethGriggs thank you for clarifying.

[mcollina]

@ovflowd the Long-Term Node.js Stewards (Proposed Title: “Node.js Collaborators”) has a real good overlap with the TSC (including emeriti) - plus some people that have been asked to become TSC members but refused or are extreme specialists of a certain area of the project.

I think the barrier to become collaborator has gone higher, and this needs fixing, because we need to encourage people to contribute more, not less. At the same time, we can land a PR with one approval after 7 days... which makes said approval even more important.

[aduh95]

Regarding the commit bit: I agree it's rarely useful nowadays, however:

• not having Write role on the repo means GitHub UI will be less useful to see how many approvals / veto a PR has¹.
• if some commits needs to be "force pushed out", having fewer folks with commit bit can make it more difficult to happen in a timely manner.
• if the commit bit is opt-in, I'm know that I would have 💯 not requested it, and would have patiently waited to become a TSC member – which maybe is fine, but I think it's been useful for the project that I had the commit bit (especially in times when the CQ was broken), and I don't think we ever had any problematic misuse of the commit bit.

tbh I'm not sure removing the commit bit would lower the bar, given that CI access and veto/approval power are IMO greater responsibilities.

Footnotes

1. maybe there's a workaround by letting everyone with Write role, but restrict permission to push on main to a subset. ↩