From cdcf10836f47664d72662309a7ee921f4b7d1333 Mon Sep 17 00:00:00 2001 From: Refael Ackermann Date: Sun, 26 Nov 2017 16:43:20 -0500 Subject: [PATCH] doc: examples for fast-tracking regression fixes --- COLLABORATOR_GUIDE.md | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/COLLABORATOR_GUIDE.md b/COLLABORATOR_GUIDE.md index c65317dd570dcf..295f16add7fef8 100644 --- a/COLLABORATOR_GUIDE.md +++ b/COLLABORATOR_GUIDE.md @@ -122,12 +122,14 @@ Before landing pull requests, sufficient time should be left for input from other Collaborators. In general, leave at least 48 hours during the week and 72 hours over weekends 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: - -* Focused changes that affect only documentation and/or the test suite. - `code-and-learn` and `good-first-issue` pull requests typically fall - into this category. -* Changes that fix regressions. +can be fast-tracked and may be landed 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. + * `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`. The pull request can be landed once 2 or more collaborators