1berry/nodejs
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

meta: add some clarification to the nomination process

Browse Source 
Update GOVERNANCE.md

PR-URL: https://github.com/nodejs/node/pull/57503
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Geoffrey Booth <webadmin@geoffreybooth.com>
Reviewed-By: Robert Nagy <ronagy@icloud.com>
Reviewed-By: Ulises Gascón <ulisesgascongonzalez@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Paolo Insogna <paolo@cowtech.it>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
Reviewed-By: Vinícius Lourenço Claro Cardoso <contact@viniciusl.com.br>
Reviewed-By: Ruy Adorno <ruy@vlt.sh>
Reviewed-By: Jordan Harband <ljharb@gmail.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Darshan Sen <raisinten@gmail.com>
Reviewed-By: Moshe Atlow <moshe@atlow.co.il>
This commit is contained in:
James M Snell 2025-03-16 09:53:26 -07:00
parent 112358539e
commit f95e43ea41
1 changed files with 85 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

100
GOVERNANCE.md
View File

@ -144,6 +144,44 @@ Contributions can be:
* Participation in other projects, teams, and working groups of the Node.js
organization.
Collaborators should be people volunteering to do unglamorous work because it's
the right thing to do, they find the work itself satisfying, and they care about
Node.js and its users. People should get collaborator status because they're
doing work and are likely to continue doing work where having the abilities that
come with collaborator status are helpful (abilities like starting CI jobs,
reviewing and approving PRs, etc.). That will usually--but, very importantly, not
always--be work involving committing to the `nodejs/node` repository. For an example
of an exception, someone working primarily on the website might benefit from being
able to start Jenkins CI jobs to test changes to documentation tooling. That,
along with signals indicating commitment to Node.js, personal integrity, etc.,
should be enough for a successful nomination.
It is important to understand that potential collaborators may have vastly
different areas and levels of expertise, interest, and skill. The Node.js
project is large and complex, and it is not expected that every collaborator
will have the same level of expertise in every area of the project. The
complexity or "sophistication" of an individual’s contributions, or even their
relative engineering "skill" level, are not primary factors in determining
whether they should be a collaborator. The primary factors do include the quality
of their contributions (do the contributions make sense, do they add value, do
they follow documented guidelines, are they authentic and well-intentioned,
etc.), their commitment to the project, can their judgement be trusted, and do
they have the ability to work well with others.
#### The Authenticity of Contributors
The Node.js project does not require that contributors use their legal names or
provide any personal information verifying their identity.
It is not uncommon for malicious actors to attempt to gain commit access to
open-source projects in order to inject malicious code or for other nefarious
purposes. The Node.js project has a number of mechanisms in place to prevent
this, but it is important to be vigilant. If you have concerns about the
authenticity of a contributor, please raise them with the TSC. Anyone nominating
a new collaborator should take reasonable steps to verify that the contributions
of the nominee are authentic and made in good faith. This is not always easy,
but it is important.
### Nominating a new Collaborator
To nominate a new Collaborator:
@ -153,10 +191,10 @@ To nominate a new Collaborator:
the nominee's contributions (see below for an example).
2. **Optional but strongly recommended**: After sufficient wait time (e.g. 72
hours), if the nomination proposal has received some support and no explicit
block, add a comment in the private discussion stating you're planning on
opening a public issue, e.g. "I see a number of approvals and no block, I'll
be opening a public nomination issue if I don't hear any objections in the
next 72 hours".
block, and any questions/concerns have been addressed, add a comment in the
private discussion stating you're planning on opening a public issue, e.g.
"I see a number of approvals and no block, I'll be opening a public
nomination issue if I don't hear any objections in the next 72 hours".
3. **Optional but strongly recommended**: Privately contact the nominee to make
sure they're comfortable with the nomination.
4. Open an issue in the [nodejs/node][] repository. Provide a summary of
@ -189,10 +227,14 @@ Example of list of contributions:
organization
* Other participation in the wider Node.js community
The nomination passes if no collaborators oppose it after one week, and if the
nominee publicly accepts it. In the case
of an objection, the TSC is responsible for working with the individuals
involved and finding a resolution.
The nomination passes if no collaborators oppose it (as described in the
following section) after one week. In the case of an objection, the TSC is
responsible for working with the individuals involved and finding a resolution.
The TSC may, following typical TSC consensus seeking processes, choose to
advance a nomination that has otherwise failed to reach a natural consensus or
clear path forward even if there are outstanding objections. The TSC may also
choose to prevent a nomination from advancing if the TSC determines that any
objections have not been adequately addressed.
#### How to review a collaborator nomination
@ -203,13 +245,8 @@ adding a feature:
* If you are neutral, or feel you don't know enough to have an informed opinion,
it's certainly OK to not interact with the nomination.
* If you think the nomination was made too soon, or can be detrimental to the
project, share your concerns, ideally before the public nomination is opened,
and avoid sharing those concerns outside of the Collaborator discussion area.
Ideally, list what step(s) the nominee could take that would make you
approve their nomination.
Given that there is no "Request for changes" feature in discussions and issues,
try to be explicit when your comment is expressing a blocking concern.
Similarly, once the blocking concern has been addressed, explicitly say so.
project, share your concerns. See the section "How to oppose a collaborator
nomination" below.
Our goal is to keep gate-keeping at a minimal, but it cannot be zero since being
a collaborator requires trust (collaborators can start CI jobs, use their veto,
@ -217,6 +254,39 @@ push commits, etc.), so what's the minimal amount is subjective, and there will
be cases where collaborators disagree on whether a nomination should move
forward.
Refrain from discussing or debating aspects of the nomination process
itself directly within a nomination private discussion or public issue.
Such discussions can derail and frustrate the nomination causing unnecessary
friction. Move such discussions to a separate issue or discussion thread.
##### How to oppose a collaborator nomination
An important rule of thumb is that the nomination process is intended to be
biased strongly towards implicit approval of the nomination. This means
discussion and review around the proposal should be more geared towards "I have
reasons to say no..." as opposed to "Give me reasons to say yes...".
Given that there is no "Request for changes" feature in discussions and issues,
try to be explicit when your comment is expressing a blocking concern.
Similarly, once the blocking concern has been addressed, explicitly say so.
Explicit opposition would typically be signaled as some form of clear
and unambiguous comment like, "I don't believe this nomination should pass".
Asking clarifying questions or expressing general concerns is not the same as
explicit opposition; however, a best effort should be made to answer such
questions or addressing those concerns before advancing the nomination.
Opposition does not need to be public. Ideally, the comment showing opposition,
and any discussion thereof, should be done in the private discussion _before_
the public issue is opened. Opposition _should_ be paired with clear suggestions
for positive, concrete, and unambiguous next steps that the nominee can take to
overcome the objection and allow it to move forward. While such suggestions are
technically optional, they are _strongly encouraged_ to prevent the nomination
from stalling indefinitely or objections from being overridden by the TSC.
Remember that all private discussions about a nomination will be visible to
the nominee once they are onboarded.
### Onboarding
After the nomination passes, a TSC member onboards the new collaborator. See