The state of nomination process and the meaning of being a core collaborator. #1702
Comments
|
cc @nodejs/tsc -- Also, apologies for the bit of LLM; I tried to rephrase things to sound better and easier to understand. :) |
|
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. |
|
+1, I'd always interpreted 'Core Collaborator' by the dictionary noun meaning:
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.) |
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. |
|
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. |
|
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? |
|
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? |
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. |
|
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.) |
I recall that... It was tough to watch.
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.
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 🙈
To be honest, I don't think collaborator re-education would work at this point; it would just cause more confusion. |
|
Hi folks, The two distinctions raised make some sense. Pragmatically, what would this mean, though?
|
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.
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. |
|
@BethGriggs thank you for clarifying. |
|
@ovflowd the 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. |
|
Regarding the commit bit: I agree it's rarely useful nowadays, however:
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
|
|
For my part I would prefer us to get back to making it easier to get a commit bit. As has been pointed out we have plenty of other processes in place to apply guard rails. As @mcollina states we already have a clear distinction between the TSC ("Long-Term Stewards") and the regular base of collaborators. The bar to becoming a TSC member is necessarily and rightfully much higher than becoming a Collaborator. So I'm not sure what improvement any further distinction there would make. My I suggest a different approach here. Let's not start with any kind of proposal for what an alternative structure might be but instead with a delineation of what the problem are that people believe need to be fixed. Do we agree that those are problems that need to be fixed? For instance, so far I've seen a couiple folks express that they are confused by the acceptance criteria for collaborators and a couple others express that they feel the criteria are too limited and subjective. Are there others? Once we identify the problems can we identify if those are actually caused by our process? I guess I'm still stuck on the basic premise here as I am not seeing a problem with our current nomination process. |
From my experience, the current situation is already affecting engagement. For instance, I have hesitated to nominate anyone due to concerns about the validation process. It's clear that many contributors who are highly active and significantly contributing to the project, though not necessarily in the Node core technical areas, may face scrutiny and potential rejection. This creates an environment where valuable contributions might be overlooked simply because they don’t align with a narrow definition of "technical relevance." Some nomination discussions have been particularly difficult to observe. Frankly, it’s challenging and not what I expected from a community like Node.js, especially from individuals in leadership positions. It's important to recognize that leadership behaviors set the tone for the broader community. When objections appear to undervalue certain types of contributions, it risks discouraging those who provide critical but less visible support.
I completely agree with this sentiment and believe it highlights a core issue. Recognizing diverse contributions is essential for the long-term health and sustainability of the project. Every contributor —whether working on Node core or any other area— plays a vital role in our collective success. By broadening how we recognize these efforts, we reinforce not just our output but the resilience and inclusivity of our community. Most of our work is public, trackable, and measurable. Tools like LFX Metrics offer clear insights into how individuals are engaging with the project and how this evolves over time, regardless of who is considered "qualified" or "suitable" to be a collaborator by us. If write access to the Node.js repository is a concern, we could consider making it optional, something collaborators can request when appropriate. We already have systems and policies in place to mitigate risks associated with this level of access. Additionally, it's concerning that some past objections to collaborator nominations appeared to undervalue contributions outside the core technical scope. This reflects a lack of empathy for the diverse ways people support the project. |
For folks who never contribute to nodejs/node, I agree that commit bit would not be relevant, and maybe it would make sense if we want to nominate folks who contribute in other areas to reserve the commit bit to a subteam. |
|
I'd much prefer this distinction to not be necessary, it wasn't in the past and we regularly accepted nominations of those who didn't have many core commits but demonstrated positive engagement by other means (other WGs, build, etc.). It's very othering to some of us to know that the contributions that supported our original nomination wouldn't be enough today, and we'd have never got the chance to grow in the project. It's sad to watch. |
|
I don't really have strong opinion who can or can't be a collaborator (without commit rights at least). However, if "collaborator" status is a way to recognise people's contributions, if we make the bar to become a "collaborator" lower it also reduces the value of the recognition. Both for past, current and future collaborators. I think the human factor of this in regards to current collaborators might be contributing to some of the friction. |
|
In the past, I get the feeling that the current process has failed us when the following conditions took place:
Is it that we put a time limit on private nominations and once it's made public we collaborators should refrain from raising objections? |
If we ask folks to remain silent after the public issue is opened, we might as well skip the public issue. I'd prefer we find a way that doesn't require making the process more opaque or less open to feedback. IMO we could already remove a lot of pain by requiring having a comment on the private discussion giving a heads up before opening the public issue, I've opened nodejs/node#57483 to include that |
This zero-sum view wrongly assumes recognition is finite, ignoring that inclusivity can enhance collaboration rather than devalue it. |
Can't both be true at the same time? The way we think people should think does not always necessarily align with reality. |
That's my goal. People with commit bit should have low entry barrier as suggested by you and @Trott on the nodejs/collaborators issue. But core collaborators or long standing collaborators or whatever we call it should be given to the peolle that have been here for a long time and that are heavily involved with the project or something like that :) |
I disagree. The TSC are the admins, superpower users. The barrier for TSC so far feels unreasonably high and I dont think many people should be within the TSC. I don't think the TSC is for long standing members but people that administer and steer the project. |
+1 |
FYI that my take is the opposite. Core Contributors have a lower barrier, just similar to the ones we've been accepting. Significant commits, few months of contribution. Then Core Collaborators or whatever we call them would be people that have been here for at least 1 year or done significant work or whatever criteria we decide, but I believe it should value the people doing long standing work. |
|
For me, it is a feature and not a bug if something reduces the status-value of being a collaborator. I don't want people seeking (or trying to hold onto) collaborator status for reasons like career advancement or the gratification of public recognition. Public recognition is great; I just don't want it to be conferred by collaborator status. Collaborators should be people volunteering to do unglamorous work because it's the right thing to do, they find the work itself satisfying, and they care about Node.js and its users. People should get collaborator status because they're doing work and are likely to continue doing work where having the abilities that come with collaborator status are helpful. (That will usually--but, very importantly, not always--be work involving commiting to the nodejs repository. For an example of an exception, someone working primarily on the website might benefit from being able to start Jenkins CI jobs to test changes to documentation tooling. That, along with signals indicating commitment to Node.js, personal integrity, etc., should be enough for a successful nomination, in my opinion.) Ideally, collaborators should be seen as public servants, stewards, custodians, caretakers, etc. and not high status holders. If there is consensus around it, I would like a sentence or two added to the nomination and onboarding docs indicating that collaborator nominations are for those types of reasons and should never be used or treated like a reward. (Related: We certainly need highy-skilled programmers as collaborators, but not all highly-skilled programmers would make good collaborators, and not all great collaborators are highly-skilled programmers.) |
|
Big +1 to everything @Trott said. I would also just add that somewhere along the way our nomination process seems to have turned into "Give me reasons to say yes, otherwise I'm blocking" rather than the "I have reasons to say no" approach that was always originally intended. I think this shift is partly to blame for the "collaborator status as a reward" mentality we're seeing, i.e. "Yay! They did enough and proved they're skilled enough to be recognized!". |
|
Based on discussion, my suggested updates to the nomination process (directly includes @Trott's comments above) : nodejs/node#57503 |
With the PR above, I feel comfortable closing this issue. At least my own concerns are dismissed. |
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:
nodejs/noderepository – 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?
The text was updated successfully, but these errors were encountered: