mirror of
https://github.com/nodejs/node.git
synced 2025-04-28 05:25:19 +00:00
doc: add review guidelines for collaborator nominations
PR-URL: https://github.com/nodejs/node/pull/57449 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com> Reviewed-By: Darshan Sen <raisinten@gmail.com> Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com> Reviewed-By: Paolo Insogna <paolo@cowtech.it> Reviewed-By: Michael Dawson <midawson@redhat.com> Reviewed-By: Chengzhong Wu <legendecas@gmail.com> Reviewed-By: Ulises Gascón <ulisesgascongonzalez@gmail.com>
This commit is contained in:
parent
8a5a849a44
commit
ee0a006a20
@ -183,6 +183,34 @@ Collaborators might overlook someone with valuable contributions. In that case,
|
||||
the contributor may open an issue or contact a collaborator to request a
|
||||
nomination.
|
||||
|
||||
#### How to review a collaborator nomination
|
||||
|
||||
A collaborator nomination can be reviewed in the same way one would review a PR
|
||||
adding a feature:
|
||||
|
||||
* If you see the nomination as something positive to the project, say so!
|
||||
* 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.
|
||||
|
||||
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,
|
||||
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.
|
||||
|
||||
When concerns have been raised on the private discussion, refrain from opening
|
||||
the public issue. If no one has explicitly blocked the nomination and you'd like
|
||||
it to move forward, comment something like "If I don't hear any objections
|
||||
before (some time), I will open the public issue".
|
||||
|
||||
### Onboarding
|
||||
|
||||
After the nomination passes, a TSC member onboards the new collaborator. See
|
||||
|
Loading…
Reference in New Issue
Block a user