doc: update collaborator guide

This also updates some parts of the onboarding. It is mainly about
how to handle pull requests, how and when to start a CI, when to add
the `ready` label and some other minor changes.

PR-URL: https://github.com/nodejs/node/pull/19116
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Minwoo Jung <minwoo@nodesource.com>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Chen Gang <gangc.cxy@foxmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Vse Mozhet Byt <vsemozhetbyt@gmail.com>
Reviewed-By: Glen Keane <glenkeane.94@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>

1 files changed, 12 insertions, 8 deletions

diff --git a/doc/onboarding.md b/doc/onboarding.md
index 17d5e74f41..421511874f 100644
--- a/doc/onboarding.md
+++ b/doc/onboarding.md
@@ -91,6 +91,10 @@ onboarding session.
       `semver-major` label
     * When adding a `semver-*` label, add a comment explaining why you're adding
       it. Do it right away so you don't forget!
+  * Please add the `author-ready` label for PRs where:
+    * the CI has been started (not necessarily finished),
+    * no outstanding review comments exist and
+    * at least one collaborator approved the PR.
 
 * [**See "Who to CC in issues"**][who-to-cc]
   * This will come more naturally over time
@@ -112,11 +116,11 @@ onboarding session.
 
 * The primary goal is for the codebase to improve.
 * Secondary (but not far off) is for the person submitting code to succeed. A
-    pull request from a new contributor is an opportunity to grow the community.
+  pull request from a new contributor is an opportunity to grow the community.
 * Review a bit at a time. Do not overwhelm new contributors.
   * It is tempting to micro-optimize. Don't succumb to that temptation. We
-      change V8 often. Techniques that provide improved performance today may be
-      unnecessary in the future.
+    change V8 often. Techniques that provide improved performance today may be
+    unnecessary in the future.
 * Be aware: Your opinion carries a lot of weight!
 * Nits (requests for small changes that are not essential) are fine, but try to
   avoid stalling the pull request.
@@ -127,15 +131,15 @@ onboarding session.
   by tools but are not, consider implementing the necessary tooling.
 * Minimum wait for comments time
   * There is a minimum waiting time which we try to respect for non-trivial
-      changes so that people who may have important input in such a distributed
-      project are able to respond.
+    changes so that people who may have important input in such a distributed
+    project are able to respond.
   * For non-trivial changes, leave the pull request open for at least 48 hours
-      (72 hours on a weekend).
+    (72 hours on a weekend).
   * If a pull request is abandoned, check if they'd mind if you took it over
-      (especially if it just has nits left).
+    (especially if it just has nits left).
 * Approving a change
   * Collaborators indicate that they have reviewed and approve of the changes in
-      a pull request using Github’s approval interface
+    a pull request using Github’s approval interface
   * Some people like to comment `LGTM` (“Looks Good To Me”)
   * You have the authority to approve any other collaborator’s work.
   * You cannot approve your own pull requests.