From 28e9a16afec1365aef4166c4a570944ffea6b7a2 Mon Sep 17 00:00:00 2001 From: Rich Trott Date: Tue, 4 Dec 2018 21:45:37 -0800 Subject: [PATCH] doc: revise Waiting for Approvals documentation Revise the Waiting for Approvals section of the Collaborator Guide. Keep sentences short and clear. Split long paragraphs into shorter paragraphs. PR-URL: https://github.com/nodejs/node/pull/24845 Reviewed-By: Richard Lau Reviewed-By: Daniel Bevenius Reviewed-By: Colin Ihrig Reviewed-By: Anto Aravinth Reviewed-By: Vse Mozhet Byt Reviewed-By: Jeremiah Senkpiel --- COLLABORATOR_GUIDE.md | 32 +++++++++++++++++--------------- 1 file changed, 17 insertions(+), 15 deletions(-) diff --git a/COLLABORATOR_GUIDE.md b/COLLABORATOR_GUIDE.md index d270903c2eadc3..48915c4fc4085a 100644 --- a/COLLABORATOR_GUIDE.md +++ b/COLLABORATOR_GUIDE.md @@ -147,28 +147,30 @@ the TSC meeting agenda. ### Waiting for Approvals -Before landing pull requests, sufficient time should be left for input -from other Collaborators. In general, leave at least 48 hours to account for -international time differences and work schedules. However, certain types of -pull requests can be fast-tracked and may be landed after a shorter delay. For -example: +Before landing pull requests, allow 48 hours for input from other Collaborators. +Certain types of pull requests can be fast-tracked and may land after a shorter +delay. For example: * Focused changes that affect only documentation and/or the test suite: - * `code-and-learn` tasks typically fall into this category. + * `code-and-learn` tasks often fall into this category. * `good-first-issue` pull requests may also be suitable. * Changes that fix regressions: * Regressions that break the workflow (red CI or broken compilation). * Regressions that happen right before a release, or reported soon after. -When a pull request is deemed suitable to be fast-tracked, label it with -`fast-track` and add a comment that collaborators may upvote. Please mention any -Collaborators that previously approved the pull request. If someone disagrees -with the fast-tracking request, remove the label and leave a comment indicating -why the pull request should not be fast-tracked. The pull request can be landed -once two or more Collaborators approve both the pull request and the -fast-tracking request, and the necessary CI testing is done. A request to -fast-track a PR made by a different Collaborator than the pull-request author -counts as a fast-track approval. +To propose fast-tracking a pull request, apply the `fast-track` label. Then add +a comment that Collaborators may upvote. + +If someone disagrees with the fast-tracking request, remove the label. Do not +fast-track the pull request in that case. + +The pull request may be fast-tracked if two Collaborators approve the +fast-tracking request. To land, the pull request itself still needs two +Collaborator approvals and a passing CI. + +Collaborators may request fast-tracking of pull requests they did not author. +In that case only, the request itself is also one fast-track approval. Upvote +the comment anyway to avoid any doubt. ### Testing and CI