mirror of
https://github.com/nodejs/node.git
synced 2025-05-09 05:41:13 +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
|
the contributor may open an issue or contact a collaborator to request a
|
||||||
nomination.
|
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
|
### Onboarding
|
||||||
|
|
||||||
After the nomination passes, a TSC member onboards the new collaborator. See
|
After the nomination passes, a TSC member onboards the new collaborator. See
|
||||||
|
Loading…
Reference in New Issue
Block a user