meta: add some clarification to the nomination process

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>

GOVERNANCE.md

@@ -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
+   block, and any questions/concerns have been addressed, add a comment in the
-   opening a public issue, e.g. "I see a number of approvals and no block, I'll
+   private discussion stating you're planning on opening a public issue, e.g.
-   be opening a public nomination issue if I don't hear any objections in the
+   "I see a number of approvals and no block, I'll be opening a public
-   next 72 hours".
+   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
+The nomination passes if no collaborators oppose it (as described in the
-nominee publicly accepts it. In the case
+following section) after one week. In the case of an objection, the TSC is
-of an objection, the TSC is responsible for working with the individuals
+responsible for working with the individuals involved and finding a resolution.
-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,
+  project, share your concerns. See the section "How to oppose a collaborator
-  and avoid sharing those concerns outside of the Collaborator discussion area.
+  nomination" below.
-  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.
 
 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