Proposal: organization-wide mebership granting process guidelines

首先檢閱這份提案以及 nodejs/admin 儲存庫中的現有政策，接著將建議的成員資格流程與所參考的協作者提名流程進行比較。完成的標準是在 nodejs/admin 中開啟一個 pull request，其中包含已達成共識的指南，以及適用於程式碼儲存庫和非程式碼儲存庫的 README.md、CONTRIBUTING.md 和 GOVERNANCE.md 範本。

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)