Consolidate Collaborator status material in GOVERNANCE.md. PR-URL: https://github.com/nodejs/node/pull/27128 Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com> Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Beth Griggs <Bethany.Griggs@uk.ibm.com> Reviewed-By: Сковорода Никита Андреевич <chalkerx@gmail.com>
7.6 KiB
Node.js Project Governance
Collaborators
Node.js Core Collaborators maintain the nodejs/node GitHub repository. The GitHub team for Node.js Core Collaborators is @nodejs/collaborators. Their privileges include but are not limited to:
- Commit access to the nodejs/node repository
- Access to the Node.js continuous integration (CI) jobs
Both Collaborators and non-Collaborators may propose changes to the Node.js source code. The mechanism to propose such a change is a GitHub pull request. Collaborators are responsible for reviewing and merging (landing) pull requests.
At least two Collaborators must approve a pull request before the pull request can land. (One Collaborator approval is enough if the pull request has been open for more than 7 days.) Approving a pull request indicates that the Collaborator accepts responsibility for the change. Approval must be from Collaborators who are not authors of the change.
If a Collaborator opposes a proposed change, then the change cannot land. The exception is if the TSC votes to approve the change despite the opposition. Usually, involving the TSC is unnecessary. Often, discussions or further changes result in Collaborators removing their opposition.
See:
Collaborator Activities
Typical activities of a Collaborator include:
- Helping users and novice contributors
- Contributing code and documentation changes that improve the project
- Reviewing and commenting on issues and pull requests
- Participation in working groups
- Merging pull requests
The TSC can remove inactive Collaborators or provide them with Emeritus status. Emeriti may request that the TSC restore them to active status.
Technical Steering Committee
A subset of the Collaborators forms the Technical Steering Committee (TSC). The TSC has final authority over this project, including:
- Technical direction
- Project governance and process (including this policy)
- Contribution policy
- GitHub repository hosting
- Conduct guidelines
- Maintaining the list of additional Collaborators
The current list of TSC members can be found in the project README.
The operations of the TSC are governed by the TSC Charter as approved by the Node.js Foundation Board of Directors.
TSC Meetings
The TSC meets regularly in a voice conference call. The meeting is run by a designated meeting chair approved by the TSC. Each meeting is streamed on YouTube.
Items are added to the TSC agenda which are considered contentious or are modifications of governance, contribution policy, TSC membership, or release process.
The intention of the agenda is not to approve or review all patches. That should happen continuously on GitHub and be handled by the larger group of Collaborators.
Any community member or contributor can ask that something be reviewed by the
TSC by logging a GitHub issue. If consensus-seeking among TSC members fails for
a particular issue, it may be added to the TSC meeting agenda by adding the
tsc-agenda
label.
Prior to each TSC meeting, the meeting chair will share the agenda with members of the TSC. TSC members can also add items to the agenda at the beginning of each meeting. The meeting chair and the TSC cannot veto or remove items.
The TSC may invite additional persons to participate in a non-voting capacity.
The meeting chair is responsible for ensuring that minutes are taken and that a pull request with the minutes is submitted after the meeting.
Due to the challenges of scheduling a global meeting with participants in several time zones, the TSC will seek to resolve as many agenda items as possible outside of meetings using the TSC issue tracker. The process in the issue tracker is:
- A TSC member opens an issue explaining the proposal/issue and @-mentions @nodejs/tsc.
- After 72 hours, if there are two or more
LGTM
s from other TSC members and no explicit opposition from other TSC members, then the proposal is approved. - If there are any TSC members objecting, then a conversation ensues until either the proposal is dropped or the objecting members are persuaded. If there is an extended impasse, a motion for a vote may be made.
Collaborator Nominations
Any existing Collaborator can nominate an individual making significant and valuable contributions across the Node.js organization to become a new Collaborator.
To nominate a new Collaborator, open an issue in the nodejs/node repository, with a summary of the nominee's contributions, for example:
- Commits in the nodejs/node repository.
- Can be shown using the link
https://github.com/nodejs/node/commits?author=${GITHUB_ID}
(replace${GITHUB_ID}
with the nominee's GitHub ID).
- Can be shown using the link
- Pull requests and issues opened in the nodejs/node repository.
- Can be shown using the link
https://github.com/nodejs/node/pulls?q=author%3A${GITHUB_ID}+
- Can be shown using the link
- Comments and reviews on issues and pull requests in the
nodejs/node repository
- Can be shown using the links
https://github.com/nodejs/node/pulls?q=reviewed-by%3A${GITHUB_ID}+
andhttps://github.com/nodejs/node/pulls?q=commenter%3A${GITHUB_ID}+
- Can be shown using the links
- Assistance provided to end users and novice contributors
- Participation in other projects, teams, and working groups of the
Node.js organization
- Can be shown using the links
https://github.com/search?q=author%3A${GITHUB_ID}++org%3Anodejs&type=Issues
andhttps://github.com/search?q=commenter%3A${GITHUB_ID}++org%3Anodejs&type=Issues
- Can be shown using the links
- Other participation in the wider Node.js community
Mention @nodejs/collaborators in the issue to notify other Collaborators about the nomination.
If there are no objections raised by any Collaborators one week after the issue is opened, the nomination will be considered as accepted. Should there be any objections against the nomination, the TSC is responsible for working with the individuals involved and finding a resolution. The nomination must be approved by the TSC, which is assumed when there are no objections from any TSC members.
Prior to the public nomination, the Collaborator initiating it can seek feedback from other Collaborators in private using the GitHub discussion page of the Collaborators team, and work with the nominee to improve the nominee's contribution profile, in order to make the nomination as frictionless as possible.
If individuals making valuable contributions do not believe they have been considered for a nomination, they may log an issue or contact a Collaborator directly.
Onboarding
When the nomination is accepted, the new Collaborator will be onboarded by a TSC member. See the onboarding guide on details of the onboarding process. In general, the onboarding should be completed within a month after the nomination is accepted.
Consensus Seeking Process
The TSC follows a Consensus Seeking decision-making model as described by the TSC Charter.