meta: improve definition of a collaborator

[jasnell]

Expand definition of Collaborator to include individuals
with commit access to any Node.js GitHub repository.

Clarify the kinds of things that should be considered when
considering inviting new collaborators

[benjamingr]

Maybe we should change the phrasing on the home page to 'core collaborators' to prevent confusion?

[jasnell]

@benjamingr ... that's fine but can be done in a separate PR

[Trott]

I support the spirit of this, but this is in contradiction with (and is unworkable with) a large amount of our current governance policies etc. We'd need to change a lot of other things (which we can totally do!) before this can land. A few that come just off the top of my head:

• Collaborators are listed in the README. This definition will expand that list by hundreds of people. It will remove clarity about who can land PRs in core.

• @-nodejs/collaborators no longer maps to the complete list of collaborators.

• The bulk of the COLLABORATORS_GUIDE is written with the assumption that the individual has access to start CI jobs, land code in the core repo, etc.

Oh, hey, looks like this has already kinda-sorta been addressed.

[addaleax]

As I understood it, this would still keep the individual collaborator groups separate, just point out that the term “Collaborator” refers to any collaborator on repositories within the organization?

[Trott]

Partial list of things that will need to happen if this lands:

• We'll need to update "Collaborator" to "Core Collaborator" in a lot of places: the README, the COLLABORATORS_GUIDE, probably some other parts of this very GOVERNANCE doc...

• We'll need to add a definition for "Core Collaborator". (Could be tricky to keep it from implying a hierarchy, if that's what we're trying to avoid with this change.)

• We'll need to update the name of the nodejs/collaborators team.

• We'll have to change the name of the COLLABORATORS_GUIDE.

[Trott]

As I understood it, this would still keep the individual collaborator groups separate, just point out that the term “Collaborator” refers to any collaborator on repositories within the organization?

@addaleax This document does not use the term that way, even after this change. The way it's being defined in this change, members of the Website WG or Build WG are Collaborators. Which: Cool! But the immediate next sentence of the doc says that Collaborators are selected by the CTC. Those folks are not selected by the CTC.

[Trott]

This is a great clear statement, but it is in apparent contradiction with both the preceding sentence and the immediately following sentence. I'm a fan of trying to use terminology in an inclusive way, but this doc needs to be treated with considerable care.

[Trott]

I like the additional text in the paragraph explaining what should be considered for Collaborator nominations. The re-definition of the term Collaborator is well-intentioned but problematic from a practical point of view IMO. Might we split that out into a separate PR? The additional text in the second later paragraph is not dependent on the definition change and we could land that relatively quickly.

[jasnell]

@Trott, feel free to push commits to the branch with the specific language you'd prefer. I trust you implicitly on your judgement there so there's no reason to seek my approval to land suggested changes.

[Trott]

@Trott, feel free to push commits to the branch with the specific language you'd prefer. I trust you implicitly on your judgement there so there's no reason to seek my approval to land suggested changes.

@jasnell and everyone who has already approved: I did a pretty drastic overhaul. I left it as a separate commit so it could be force-pushed out if you disagree with the changes. PTAL.

[jasnell]

As I said, I trust you implicitly. The changes LGTM

[Trott]

As I understood it, this would still keep the individual collaborator groups separate, just point out that the term “Collaborator” refers to any collaborator on repositories within the organization?

I see a couple of options. One is we could put something like this in this doc:

A Node.js Collaborator is any individual having commit access to any repository in the Node.js GitHub organization. In this document and elsewhere in the nodejs/node repository, Collaborator refers specifically to people who have commit access to the nodejs/node repository.

Another option is that we could put the definition of Node.js Collaborator in a different doc. I'd suggest a doc in the TSC repo but one disadvantage to that is that it may have less visibility. (Then again, I'm not sure the GOVERNANCE doc gets a whole lot of eyeballs either, TBH.)

[gibfahn]

So all collaborators are approved by the CTC? Assuming collaborators will now roughly map to @nodejs/members, does this mean everyone who joins the org needs CTC approval? Even if they're joining CommComm for example?

Also is this the current process? If not it seems like something that could use more general members feedback.

The answer could totally be "this is a hard question, let's roll with this and improve it going forward".

EDIT: I think this is what @Trott said:

But the immediate next sentence of the doc says that Collaborators are selected by the CTC. Those folks are not selected by the CTC.

[jasnell]

"approval" does not necessarily mean implicit voting.

[gibfahn]

Sure, but identified suggests it's an active thing.

[jasnell]

This is the original language and it is definitely lacking. Specific suggestions for improvement are welcome as I'm not sure what would be better

[TimothyGu]

I believe it's important to bring active members of the Node.js community into the project somehow, but at this point I'm not convinced a contributor without much experience in working on the nodejs/node repo should be given commit access to it _{(following content is added after edit)} for the same reason that I, a Collaborator but not member of any WG, am not given commit access to any WGs' repos.

[gibfahn]

AIUI "commit access to the project" does not mean "commit access to nodejs/node", it means commit access to whichever team you get added to. So if you contribute to core you get made a core collaborator and added to @nodejs/core (assuming we change @nodejs/collaborators to that). If you contribute to the website, then you become a website collaborator and get website access.

To clarify, maybe something like:

-commit access to the project. Activities taken into consideration include (but
+commit access to that repository. Activities taken into consideration include (but

[jasnell]

We seriously need to get better at defining and clarifying the differences :-( ... going to stew on it more

[hackygolucky]

So the idea here, moving forward, is that once this gets merged, the nodejs/moderation team would be the specifically chosen group of moderators who could be @-ed as a group whenever -anyone-
who is in our GitHub community needs to request moderation, and outside of GitHub would send a request to reports@nodejs.org(which also goes to the members of nodejs/moderation). Then, the Moderation team is made fully aware that they will need to act when these flags are raised, and how to act.

The Moderation repo would then be used for moderation administration for the Moderation team, not for reporting, because that is not accessible to the entire community.

We would make sure that these instructions are IN our CoC and moderation guidelines, so anyone visiting our community knows how to flag a moderator, regardless of whether they are a collaborator.

edited: (I'd be happy to held execute on said above work)

[jasnell]

Landed in 52fe762...

I plan to take another iteration on this shortly