electron · MarshallOfSound · Sep 12, 2026 · Sep 12, 2026
@@ -2,7 +2,7 @@
 
 [![Test](https://github.com/electron/cation/actions/workflows/test.yml/badge.svg)](https://github.com/electron/cation/actions/workflows/test.yml)
 
-`cation` is Electron's PR monitoring bot, which serves four primary functions - semver label enforcement, PR open time enforcement, API review bookkeeping, and deprecation review. Each of the four are discussed in further detail below.
+`cation` is Electron's PR monitoring bot, which serves three primary functions - semver label enforcement, API review bookkeeping, and deprecation review. Each of the three are discussed in further detail below.
 
 ## Semver Label
 
@@ -16,18 +16,6 @@ This bot is responsible for ensuring that all open PRs to Electron are labeled w
 
 <img width="739" alt="Screen Shot 2020-12-16 at 9 15 48 AM" src="https://user-images.githubusercontent.com/2036040/102382563-6f8f7080-3f7f-11eb-8fd8-f0ccd2672957.png">
 
-## PR Open Time
-
-The bot is also responsible for ensuring that any given PR is open for an amount of time that reflects its impact on user-facing code. This is also done to ensure that all potential stakeholders for that PR are given ample time to review it and discuss API ergonomics amongst ways it may affect users.
-
-Timespans:
-* `semver/major` - 168 hours (7 days)
-* `semver/minor` - 168 hours (7 days)
-* `semver/patch` - 24 hours (1 day)
-* `semver/none` - 24 hours (1 days), but in some cases (depending on the PR and its goals) there is no minimum time.
-
-Backport PRs (PRs to a release branch that is not `main`) do not require a minimum time, and a `fast-track` label may be optionally applied to a PR to indicate that it is intended to bypass the expected minimum time if sufficient reason exists to do so.
-
 ## API Review
 
 The bot controls the API review lifecycle on behalf of the [API Working Group](https://github.com/electron/governance/tree/main/wg-api).
@@ -38,14 +26,16 @@ This group's review is mandated on all API changes, and their goal is twofold:
 
 Even changes that seem trivial can often be made more consistent and future-proof with some modifications, and the folks on the API WG have the expertise to spot and suggest those changes.
 
-In accordance with the above goals, this bot performs several bookkeeping duties. When a new PR is opened which is either `semver/minor` or `semver/major`, it will automatically add an `api-review/requested 🗳` label to the PR. To add clarity to whether a review is occurring in a given Electron governance member's capacity as a member of the API WG, this bot then adds a GitHub Check on the PR which will update as members of the API WG indicate their approval statuses.
+In accordance with the above goals, this bot performs several bookkeeping duties. When a new PR is opened which is either `semver/minor` or `semver/major`, it will automatically add an `api-review/requested 🗳` label to the PR. Backport PRs (PRs to a release branch that is not `main`) and PRs labeled `backport`, `backport-check-skip`, or `fast-track 🚅` are exempt from API review. To add clarity to whether a review is occurring in a given Electron governance member's capacity as a member of the API WG, this bot then adds a GitHub Check on the PR which will update as members of the API WG indicate their approval statuses.
 
 Members of the API Working Group must indicate their approval by leaving a comment via a PR Review containing `API LGTM`. This may not necessarily be a full approval with the GitHub API since approval by the API is primarily about the API shape and design. Both a PR review that comments and includes an LGTM indication or which is an approval with LGTM are sufficient.
 
 <img width="849" alt="Screen Shot 2021-11-02 at 10 46 57 AM" src="https://user-images.githubusercontent.com/2036040/139823875-af7ae01e-8c08-4733-82d0-153dced69b63.png">
 
 <img width="836" alt="Screen Shot 2021-11-02 at 10 49 27 AM" src="https://user-images.githubusercontent.com/2036040/139824356-25a06c95-d976-422c-91cf-560876e295f4.png">
 
+PRs undergoing API review must be open for a minimum of 168 hours (7 days), to ensure that all potential stakeholders for that PR are given ample time to review it and discuss API ergonomics amongst ways it may affect users. If the PR was previously a draft, this time is counted from when it was most recently marked ready for review.
+
 If a PR has passed its minimum open time and has the requisite number of approvals with no outstanding requests for changes, the bot will then switch `api-review/requested 🗳` to `api-review/approved ✅`, and the PR is free to be merged. If outstanding change requests persist, then the group will initiate consensus-seeking procedures and ultimately choose to approve or decline the PR. If the decision is made to decline, the API WG chair will then comment on the PR with `API Declined` and the bot will update `api-review/requested 🗳` to `api-review/declined ❌`.
 
 For PRs that need to land faster than the minimum open time (e.g. to respond to OS or Chromium updates), the minimum open time can be bypassed by adding a `api-review/skip-delay ⏰` label to the PR. This label may be added to a PR if at least two members of the API WG representing two different employers approve fast-tracking the PR.