Proposal: organization-wide mebership granting process guidelines

[joyeecheung]

This is a proposal for adding guidelines on how to grant membership of the Node.js GitHub organization to new contributors.

Background

The Node.js organization currently has 600+ members. We don't have a clear criteria on granting membership for every GitHub teams - when inviting someone to a GitHub team under the organization, if the box to make them an external collaborator is not checked (which is not by default), they will become a member of the Node.js organization.

Each GitHub team has their own governance model - some of them set a certain criteria for membership whereas some of them don't.

For example:

• The @nodejs/collaborators team that has write access to the @nodejs/node repository, uses a nomination based process to add new members. There is no mandatory quantifiable measures, but typically the person doing the nomination posts links of the nominee's commits, comments, issues, .etc to demonstrate why they think the nominee is eligible for membership.
• The @nodejs/automation team, on the other hand, simply added people who replied in the issue recruiting members

The second case may unconsciously aid social engineering attacks (like the event-stream incident)- for people who are not familiar with our membership policy (which is close to none other than the 2FA requirement), a membership in the Node.js organization could make someone, even a potential attacker who can be added by simply replying to an issue, look more credible. As such I feel that we (TSC and CommComm who are administrators of the Node.js organization) should take on the responsibility to at least set up guidelines for teams in the organization about granting future memberships.

Goal

The goal is to complete a certain level of due diligence when we add people to the organization (whereas in the current system the level can be zero) in the future, and to cultivate a healthy, transparent, encouraging culture for future contributions.

This proposal aims to establish non-mandatory guidelines for GitHub teams across the organization on how to achieve that.

Non-goal

It's not a goal to "vet" the existing members as that would be unnecessarily hostile. I believe we should be able to trust our existing members - but, whenever necessary, we should point out to people outside the organization about the implications (or non-implications) of membership in our organization.

Suggestions

• For any new effort in the organization - no matter it involves writing code or not - if it is anticipated that new contributors may be granted membership in the organization, existing members can set up a GitHub team and a repository in the Node.js organization. The repository should contain:
  • README.md
  • CONTRIBUTING.md (it is encouraged to add a link to the Node.js Code of Conduct
  • GOVERNANCE.md
• It is encouraged to do everything, if possible, on GitHub, or any other public, transparent forum, if reasonable. For example, discussions should be done in GitHub issues as possible. For conference calls or in-person meetings, notes should be taken and added via pull requests to the repository.
• To recruit new members for an effort, the administrators of the teams should not simply add people to the organization in a rush, unless they are already a member of the organization and have already been contributing to related efforts.
• For adding new contributors to the organization in the future:
  • Make sure there are clear instructions on how to get involved and contribute in CONTRIBUTING.md - be it code changes, participation in issues, writing up summaries, .etc
  • Set up an observation period - a recommendation would be a month. During this period the contributor is an observer. Teams can decide on how they want to give credit to observers on their own.
  • After the observation period, if the contributor has been making enough contributions to the effort so that other existing members are convinced that this person should be eligible for membership, the person can be added to the team.
• The action of adding someone to the team should be made public, either as a pull request to the README.md or as an issue for notifications. This action should be discussed among existing team members before being taken, either in public or in private. The eligibility should come from contributions in the public or in a venue that is visible to most of other team members, and can be demonstrated via links to such contributions.
• It is encouraged, but not required, to use a nomination-based process when adding new contributors - the contributor can also self-nominating themselves. The Node.js collaborator nomination process can be a good reference.

Exceptions

Exceptions may be given to employees or contractors of the Node.js Foundation as the Foundation should already perform the due diligence before signing any contract with individuals.

Plans about this proposal

I have sent my thoughts to the TSC and CommComm in private a few weeks ago for feedback and come up with the current suggestions. There were no objections to this proposal in the mailing list as far as I can tell, so I believe it's time to open this issue for further feedback among other members in the Node.js organization.

I plan to:

1. Iterate on the proposed guidelines in the next few weeks - any suggestions or opinions are welcomed! Please reply in this thread about your thoughts.
2. Draft templates for CONTRIBUTING.md, README.md and GOVERNANCE.md for code and non-code repositories.
3. Open a pull request to add a document containing the guidelines this this repository (nodejs/admin), along with the templates.
4. Spread the word and notify teams in the organization about the new guidelines.

Considering the holidays are coming I estimate that these would be completed in early next year - my current ETA is February.

cc @nodejs/tsc @nodejs/community-committee

(I will post in the nodejs/members discussion board about this but will not cc that team here so people who are not interested will not be spammed by the replies)

[mcollina]

This is a very good approach, I like it.

To recruit new members for an effort, the administrators of the teams should not simply add people to the organization in a rush, unless they are already a member of the organization and have already been contributing to related efforts.

I would add "or if a current member of the team/wg or somebody in the top level commitees recommends them". This is currently being done by the Build and Security wgs, and it works well enough from them.

[mhdawson]

I think having guidance for adding members that will join a team/working group etc will be a good thing. It will make the process clear and applied to all. I suggest we'd need some guidance around how to manage different types of team members. For example it would be useful to have 2 github teams for a particular team for example package-maintenance-members and package-maintenance-observers. The -members would be the team which is a child of the overall members team, while package-maintenance-observers would not. I think this would let us add people that we can at mention through the -observers team and provide a sense of inclusion while at the same time requiring some activity before they become part of the overall membership.

[fhemberger]

The onboarding for @nodejs/website has always been quite open. One of the reasons for this open approach was using work on the website as a stepping stone to further involvement in other Node.js WGs, like CommComm, i18n and core. (I don't know if this actually happened to be the case, but we do have a string community engagement regarding translations.)

Every contributor has been invited to the team on a regular basis. As this is a manual process, which requires manual action from a GitHub org admin, this is quite cumbersome and is already being discussed in #266. With currently 164 members, the Website WG makes up the largest team in the entire organization.

I think the upcoming website redesign will also spark quite some interest for new contributors, so I'm not sure if the current approach is still feasible for the future.

So I'm very open to suggestions, also regarding minimal requirements for joining a WG.

[joyeecheung]

@fhemberger Thanks for bringing this up. As I understand, the main repo where the website team contribute to should be https://github.com/nodejs/nodejs.org , right? (given that the only non-archived-repo that it has write access to, other than the summit repo, is nodejs/nodejs.org) I took a look that the statistics at the repo and had some interesting observations.

At the time of writing, there are 164 members in the@nodejs/website team which has write access to nodejs/nodejs.org and this is the activity of the repo in the past month:

The @nodejs/collaborators team, which has write access to nodejs/node, has 124 members and this is the activity in the past month (note that since nodejs/node does not use the GitHub UI to merge PR the number of merged PR is a bit off - judging by the number of commits, roughly 400+ PRs have been merged in the past month):

In summary the activity in the nodejs/node repo (including issues and PRs) is roughly 10x of the nodejs/nodejs.org repo, even when the size of the @nodejs/website team is 1.3x the size of @nodejs/collabotrators.

From https://github.com/nodejs/nodejs.org/blob/master/GOVERNANCE.md#collaborators

Individuals making significant and valuable contributions are made Collaborators and given commit-access to the project. These individuals are identified by the WG.

However there's no clear description on how These individuals are identified by the WG, and what is used to measure significant and valuable contributions.

I wonder whether https://github.com/nodejs/admin/issues/266 actually solves the issue, given the amount of activity in the website repo, I would've expected that the velocity of new membership should've been slower than the @nodejs/collaborators team (in my impression that's about 2-3 each month in core). Automating the invitation process seems orthogonal, if not opposite, to the goal of this proposal.

The goal is to complete a certain level of due diligence when we add people to the organization (whereas in the current system the level can be zero) in the future, and to cultivate a healthy, transparent, encouraging culture for future contributions.

Note that one do not need to be a member of any team to start contributing to a repo, so I personally do not feel that automating the invitation process would actually be effective in getting more contributors involved or getting more contributions. The point of this proposal is about putting contributions before membership, and I believe the velocity of the website repo has proven that membership does not imply contributions.

[joyeecheung]

Looking at the pulse of the website repo, I think it would not be too unreasonable to use a process similar to that of the node core repo for inviting new members, which primarily use commits, pull requests and participation in issues as measures. For example, I think it's reasonable to identify any new contributor who has been more active than, say, the top 20% of the team members in a period, and make them new members of the team (there is a tool I wrote that can do half of the job for identifying individuals like this).

[fhemberger]

At the moment, we have only 29 people with > 10 commits (total). So yes, I think it would be a good idea to apply a similar standard across the organization.

To apply those new guidelines to the website repo, we could:

1. stop adding new contributors for each commit for now
2. "reset" the team membership and applying the new guidelines on @website-redesign, which will probably become the new @website eventually.

So no one is "kicked out" of the existing team for not contributing.

I'd love some feedback from @nodejs/website on this, but don't want to hijack this thread completely. We could also split off the discussion, if you'd prefer.

[ZYSzys]

As one of @website memebers, I'm +1 on this idea:)