Reward Contributors Better - New Project Role

[benjamingr]

Being a Node.js core collaborator was intended to signify people actively working on the Node.js code base.

It has evolved to signify a certain status symbol for some people. We have in the past given collaborator status to individuals that were very involved in the project at different capacity to signify trust and contributions to the project as a whole as a result.

The debate of whether or not someone should be made a collaborator without significant code contributions (giving them namely the ability to approve/block PRs, push code directly in an emergency and run CI (which admittedly triagers can also do) came up several times.

I am 100% for celebrating the people who help make Node.js successful which to be clear absolutely includes contributions in areas other than the core code which are often as or more important. I am also totally fine with some people benefiting from said status.

So - I suggest we create a new role to celebrate these sort of significant contributions to the Node.js project: "Node.js Project Insider" (🚲 🏠 welcome).

As for process: I recommend initially projects members can nominate other project members to the TSC for the role and the TSC accepts/rejects the nomination with lazy consensus.

---

This is a very rough idea, I am not 100% convinced myself this is a good idea (but think it may be) so please participate and raise things up! @nodejs/tsc

[mhdawson]

I don't oppose this if others think its a good idea, but I don't see is as a status symbol but more ensuring people are involved in discussions, being able to run CIs etc. and otherwise act as part of the overall collaborator base within the project. There are cases where we at mention the collaborators, they have access to the moderation issues, etc.

We trust our collaborators to use the access rights we give them responsibly, for example only approving PRs for which they have the right knowledge to review, only landing PRs that meet the require criteria etc. There are even cases where the review/approval should really come from people that may not regularly land commits in core. I think a good example is the PR to fix the OSX notarization which should reallly be reviewed/approved by people in build, some of whom are not currently core collaborators.

Setting up/managing another team, having people have to at mention two teams instead of one, etc. seems like uneeded overhead given the small number of cases (In my mind) where is makes sense for people to be colllaborators without the specific core commits people are looking for.

[joyeecheung]

I think we can keep this role scoped for:

1. People who do not need commit bit in core
2. People who contribute to projects outside of core

For the case @mhdawson mentioned I think that's out of scope of this role. We could either continue using collaboratorship to manage that, or create a different team to do that, or create new permissions for existing teams. The role being proposed, however, is used to help us stop using core collaboratorship as a reward for people who contribute to other projects in the organization e.g. community management, websites. Expanding core collaboratorship to people who do not maintain core specifically may be a kind gesture but it creates a delusion that we have more core maintainers than there are, this is not healthy especially in the context of the core issue tracker being overloaded & contain many long-standing confirmed bugs. If someone asks "why no one out of these many X core collaborators can fix this long-standing bug that has a wide ecosystem impact", I don't think "many of them do not actually work on core, this role is also used as a status symbol" is a satisfying answer.

[benjamingr]

@joyeecheung you know, you're really good at articulating ideas and I'm learning a bunch just from reading your comments explaining stuff going on in my head.

[GeoffreyBooth]

If someone asks “why no one out of these many X core collaborators can fix this long-standing bug that has a wide ecosystem impact”, I don’t think “many of them do not actually work on core, this role is also used as a status symbol” is a satisfying answer.

Another way of putting it is that we’re conflating two things in the “core collaborators” role: maintaining core code, and making decisions for the project. That’s fine to combine if there’s perfect overlap between the two groups, but not if there are people who should have decision-making authority, the ability to approve and block PRs, who don’t maintain code in core. I think it’s a reasonable argument that releasers, or maintainers of important dependencies, should have a role in Node’s decision-making process even though they don’t contribute to core.

If others agree, then perhaps a better solution would be to divide the current collaborators group into two: “core collaborators,” who maintain core code, and “project collaborators,” who do other things for the project. Both would have the same privileges and powers. It would eliminate the “status symbol” aspect of being a collaborator, and Joyee’s point about misrepresenting the number of maintainers of Node.

[joyeecheung]

I think it’s a reasonable argument that releasers, or maintainers of important dependencies, should have a role in Node’s decision-making process even though they don’t contribute to core.

I agree about the general idea but do we really need the formality for this case though? I am pretty sure e.g. if V8 is strongly against some PR in Node.js core for some reason we would definitely take it seriously. Typically when disputes like this arises, it doesn't really matter if the people involved is a collaborator or not, if their opinions carry a lot of weight for some reason (being well-recognized in the community, maintaining a lot of important packages, etc.) and if they are acting on good faith, it will just go to the TSC, which is not different from the case where the people having disputes are all collaborators. If this is not really necessary for practicality, it still goes back to a status symbol.

[GeoffreyBooth]

If this is not really necessary for practicality

Theoretically, roles in general aren’t necessary for practicality, if we all know everyone and whether or not they should be trusted. With a hundred active collaborators, though, I certainly don’t know them all; and I definitely don’t know many non-collaborators whose opinions I should value, such as V8 team members. Having them on the official list means that not just that they can enforce their opinions with a block, but also that I should take that block seriously. Not that I would necessarily ignore a strong opinion or block otherwise, but it would carry much more weight coming from someone we trust.

I also don’t think it benefits the project much to have reasons to keep out collaborators who have proven that they can work well with others and whose opinions we value. There are people who should be part of the decision-making process who aren’t contributors to core code, and I think it would benefit the project if we could give them an official status if they want it, because that would encourage them to be more involved. It’s not a status symbol, because it involves both real powers (to block or approve) and responsibilities (that we expect them to help the project make good decisions, and to collaborate productively and reach consensus whenever possible). If someone gets the role and never uses it, then it would be a symbol, but we have processes for easing out inactive collaborators.

[joyeecheung]

I certainly don’t know them all; and I definitely don’t know many non-collaborators whose opinions I should value, such as V8 team members. Having them on the official list means that not just that they can enforce their opinions with a block, but also that I should take that block seriously.

Isn't that what this proposal can also solve? They don't need to be collabroators, if they are only on this list you can also trust them equally. That goes back to a status symbol. You can make use of this status symbol to evaluate how trust-worthy a stranger is. We just need to make sure that those who practically exercise the decision-making power take the opinions of those who have an honorary symbol into account, though I think that's something we've been doing already.

I also don’t think it benefits the project much to have reasons to keep out collaborators who have proven that they can work well with others and whose opinions we value. There are people who should be part of the decision-making process who aren’t contributors to core code, and I think it would benefit the project if we could give them an official status if they want it, because that would encourage them to be more involved.

I agree and that's exactly why this new role would be useful. We don't need to make one list incredibly long for this. We just need to consider other lists. For example a collaborator who has been inactive for years would lose the permission to immediately block or approve something, but they can still voice their opinions and it will be heard, they just do not have to push some button on the GitHub UI for that. This is already one additional list that we consider, I don't see why creating another list would make us less inclusive?

[joyeecheung]

To bikeshed the name a bit:

• Insider: this kind of implies that anyone else is an "outsider", which I guess we probably do not want..

• Collaborator: I actually never liked this word because for someone who does not speak English a lot, this word is very strange, it's not a word you usually find in textbooks or TV shows/movies. I was puzzled myself when I started contributing and then after I learned what it means, I had to repeat the explanation to other fellow Chinese developers when they are also puzzled by what this word means. Also as someone who does not speak English, your are likely to try looking it up in the dictionary, and...guess what, the dictionary says this is

  a person who works with an enemy who has taken control of their country

I think a term commonly found in professional or academic contexts might be cool though, like "Node.js associate" or "Node.js fellow".

[GeoffreyBooth]

I actually never liked this word

My wife always teases me whenever I say “Node collaborator.” For her it definitely implies shady treachery. (We’re both American native English speakers.)

We could just use the “team” nomenclature that we use elsewhere. “Core Team” and “Project Team,” say.

[gireeshpunathil]

how about:

• collaborator: folks who consistently contribute value to the project in any form
• maintainer: folks who are collaborators plus decision makers, and with commit bits
• in another embodiment, maintainers are scopped per repo and collaborators, the org
• in yet another embodiment, maintainers can cover multiple repos on need basis
• collaborators can become maintainers on a need basis
• contributors can directly become maintainers too
• both roles need nominations (though at different expectations and criteria)

[Trott]

If I recall correctly, we use the term "Collaborator" because that is (or was?) the terminology GitHub uses (or used in the past?).

As for creating a sort of "gold star badge" kind of role to celebrate people who contribute: The intentions are (of course) good and my opposition is very mild, so not blocking. But I think it (unintentionally) adds a sort of gamification element to contributions. There are already elements like that, and I'd like to minimize them and avoid creating new avenues of gamification.

But this concern of mine is very mild. It's enough of a concern that I feel compelled to mention it, but not enough of a concern to block any proposal that has the support of TSC and collaborators.

[GeoffreyBooth]

I still think the simplest solution is to just rename Collaborator to Core Team Member, and create a new role Project Team Member. They each have the same privileges for approving or blocking PRs, but the Project Team Members are primarily responsible for tasks other than core code (releases, triage, help, documentation, website, etc.).

Benefits:

• Moves away from problematic term “collaborator”
• Addresses concern about there being too many collaborators; this makes clear how many code maintainers the project has
• Empowers important teammates who we want to have a say in decision-making