summaryrefslogtreecommitdiff
path: root/doc/onboarding.md
diff options
context:
space:
mode:
authorRich Trott <rtrott@gmail.com>2018-08-11 20:57:01 -0700
committerRich Trott <rtrott@gmail.com>2018-10-04 16:32:39 -0700
commit2f117e1cd83fb8c34e1ff135a15d472c2dab4f89 (patch)
tree895e70f2d890549233f52fc1371f095424966913 /doc/onboarding.md
parent26af72899417525dd32372d63c07ee5aa1ab6c5c (diff)
downloadandroid-node-v8-2f117e1cd83fb8c34e1ff135a15d472c2dab4f89.tar.gz
android-node-v8-2f117e1cd83fb8c34e1ff135a15d472c2dab4f89.tar.bz2
android-node-v8-2f117e1cd83fb8c34e1ff135a15d472c2dab4f89.zip
doc: leave pull requests open for 72 hours
Currently, we have a 48/72 rule for how many hours a pull request should be left open at a minimum. Unfortunately, whether a pull request should be left open for 48 or 72 hours is often unclear. The 72 hours is required if it is a weekend. If I open a pull request on a Friday morning, does it need to stay open 48 hours or 72 or something in between? Does it matter if I'm in one time zone or another? The 48/72 rule predates our fast-tracking process. Given the ability to fast-track trivial pull requests, there should be little disadvantage to leaving significant changes open for 72 hours instead of 48 hours, and arguably considerable advantage in terms of allowing people sufficient time to review things. So to simplify, standardize on 72 hours. Weekend or not, 72 hours. Easy. PR-URL: https://github.com/nodejs/node/pull/22275 Reviewed-By: John-David Dalton <john.david.dalton@gmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com> Reviewed-By: Сковорода Никита Андреевич <chalkerx@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Brian White <mscdex@mscdex.net> Reviewed-By: Jon Moss <me@jonathanmoss.me> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Ben Coe <bencoe@gmail.com> Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com> Reviewed-By: Refael Ackermann <refack@gmail.com> Reviewed-By: João Reis <reis@janeasystems.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com> Reviewed-By: Rod Vagg <rod@vagg.org>
Diffstat (limited to 'doc/onboarding.md')
-rw-r--r--doc/onboarding.md5
1 files changed, 2 insertions, 3 deletions
diff --git a/doc/onboarding.md b/doc/onboarding.md
index 3a03edb17e..bd9418fd91 100644
--- a/doc/onboarding.md
+++ b/doc/onboarding.md
@@ -138,8 +138,7 @@ onboarding session.
* 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.
- * For non-trivial changes, leave the pull request open for at least 48 hours
- (72 hours on a weekend).
+ * For non-trivial changes, leave the pull request open for at least 72 hours.
* If a pull request is abandoned, check if they'd mind if you took it over
(especially if it just has nits left).
* Approving a change
@@ -215,7 +214,7 @@ needs to be pointed out separately during the onboarding.
* Run CI on the PR. Because the PR does not affect any code, use the
`node-test-pull-request-lite-pipeline` CI task.
* After one or two approvals, land the PR (PRs of this type do not need to wait
- for 48/72 hours to land).
+ for 72 hours to land).
* Be sure to add the `PR-URL: <full-pr-url>` and appropriate `Reviewed-By:`
metadata.
* [`node-core-utils`][] automates the generation of metadata and the landing