Commit 873887c2154 for woocommerce
commit 873887c2154aa0a649c25d238d0616916fb6ba3d
Author: Rafael Meneses <meneses.tio@gmail.com>
Date: Wed Oct 7 09:39:57 2026 -0300
Make the release readiness and go/no-go steps actionable (#69463)
* docs(releases): make the RC readiness items actionable
The readiness items said what to decide but not where to look or what
to record. Name the source for each item and record the result as a
comment on the GitHub issue.
Refs ARC-1855
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* docs(releases): hold the go/no-go after RC staging
The go/no-go was due 24-48 hours before stable, which is before the RC
exists. Hold it after RC staging, before the stable build, and record
the decision on the GitHub issue.
Refs ARC-1855
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* docs(releases): drop private channel names from the sweep items
Refs ARC-1855
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
diff --git a/.linear/release-kickoff-patch.md b/.linear/release-kickoff-patch.md
index 9a84d2aa828..c60d1233ab8 100644
--- a/.linear/release-kickoff-patch.md
+++ b/.linear/release-kickoff-patch.md
@@ -12,11 +12,11 @@ Keep the _[Release Troubleshooting & Recovery](https://developer.woocommerce.com
### 1. Go/no-go
-For scheduled stable releases, hold this 24-48 hours before the release date with the Product DRIs named on the parent tracking issue - ping `@woo-core-release` in Slack if you need to reach them or aren't sure who's available. Bring in QualityOps and the Atomic contact when staging or monitoring left open questions. See the [readiness guide](https://developer.woocommerce.com/docs/contribution/releases/readiness/) for details.
+For scheduled stable releases, hold this after the RC has finished its staging monitoring and before starting the build below, with the Product DRIs named on the parent tracking issue - ping `@woo-core-release` in Slack if you need to reach them or aren't sure who's available. Bring in QualityOps and the Atomic contact when staging or monitoring left open questions. See the [readiness guide](https://developer.woocommerce.com/docs/contribution/releases/readiness/) for details.
-- [ ] The readiness review is complete and its verdicts still hold.
-- [ ] No new blocking findings since the readiness review (check `#woo-core-releases` threads and the [newest issues]({repository_url}/issues?q=is%3Aissue%20state%3Aopen%20sort%3Acreated-desc)).
-- [ ] Decision recorded as a comment on this issue - **go**, **no-go**, or **go with conditions** - with the names behind it.
+- [ ] **Readiness still holds.** For a scheduled release, re-read the readiness comments on the RC sub-issue and record what changed since: new findings with their verdicts, and fixes merged into the release branch after the RC, noting whether each ran on staging. For a point release, run the readiness criteria as described below.
+- [ ] **RC evidence** (scheduled releases). Open the QIT sweep for the RC and the staging thread from step 5 of the RC sub-issue. Record both links and a verdict for anything new.
+- [ ] **Decision.** Comment on this GitHub issue: **go**, **no-go**, or **go with conditions** (list them), with the names behind it. A new comment thread started on the Linear mirror does not sync back here.
For scheduled releases, the readiness review is the one in the RC sub-issue. Point releases have no RC: run the [readiness criteria](https://developer.woocommerce.com/docs/contribution/releases/readiness/) over the changes being shipped as part of this go/no-go, with verdicts per the [release decision matrix](https://developer.woocommerce.com/docs/contribution/releases/decision-matrix/). For unscheduled point releases shipping an urgent fix, a quick go/no-go with `@woo-core-release` in `#woo-core-releases` is enough - record the outcome here all the same.
diff --git a/.linear/release-kickoff-rc.md b/.linear/release-kickoff-rc.md
index fcc6ed1353c..776c4025fa8 100644
--- a/.linear/release-kickoff-rc.md
+++ b/.linear/release-kickoff-rc.md
@@ -12,12 +12,14 @@ Keep the _[Release Troubleshooting & Recovery](https://developer.woocommerce.com
### 1. Release readiness review
-Go through this checklist together with the Product DRIs named on the parent tracking issue before starting the build - ping `@woo-core-release` in Slack if you need to reach them or aren't sure who's available. The goal is a deliberate "this RC is ready to go out" call, with the evidence in one place. See the [readiness guide](https://developer.woocommerce.com/docs/contribution/releases/readiness/) for details on each item.
+Run this with the Product DRIs named on the parent tracking issue before starting the build - ping `@woo-core-release` in Slack if you need to reach them or aren't sure who's available. The RC doesn't exist yet, so the evidence is the latest beta and everything reported since feature freeze. See the [readiness guide](https://developer.woocommerce.com/docs/contribution/releases/readiness/) for details on each item.
-- [ ] Review the QIT compatibility regression sweep report for this prerelease. Every introduced issue has a verdict: blocking or not; non-blocking findings get their full verdict in the next item.
-- [ ] Every open finding against this release (bug reports, testing threads, monitoring alerts, non-blocking QIT sweep findings) has a linked issue and a verdict per the [release decision matrix](https://developer.woocommerce.com/docs/contribution/releases/decision-matrix/): release-blocking / fix in a point release / next release / not a bug.
-- [ ] The rollback path for this release is known: who reverts, how, and what revert means for this version (see the [troubleshooting guide](https://developer.woocommerce.com/docs/contribution/releases/troubleshooting/)).
-- [ ] Comms are ready: the changelog is in shape and there's a known-issues list if the verdicts above left anything open.
+Record each item as a comment on this GitHub issue: the links you checked and the verdict. A new comment thread started on the Linear mirror does not sync back here.
+
+- [ ] **Compatibility sweep.** Open the QIT compatibility regression sweep for the latest beta. Record the run link and, for each introduced issue, whether it blocks the release.
+- [ ] **Open findings.** Check the comments on this cycle's pre-release notes post on the developer blog, the [WordPress.org support forum](https://wordpress.org/support/plugin/woocommerce/), the canonical extensions testing post, and the [GitHub issues opened since feature freeze]({repository_url}/issues?q=is%3Aissue%20sort%3Acreated-desc). Record each finding that touches code in this release with its issue link and a verdict per the [release decision matrix](https://developer.woocommerce.com/docs/contribution/releases/decision-matrix/): release-blocking / fix in a point release / next release / not a bug. For the rest, record how many you checked and why they don't apply.
+- [ ] **Rollback path.** Record who reverts and how, and anything in this release that a revert would not undo, such as database migrations or new settings (see the [troubleshooting guide](https://developer.woocommerce.com/docs/contribution/releases/troubleshooting/)).
+- [ ] **Comms.** Record that the changelog is reviewed, and the known-issues list for the release post - or "none".
If an item can't be checked, raise it in `#woo-core-releases` before continuing - delaying an RC is cheaper than reverting a stable.
diff --git a/docs/contribution/releases/readiness.md b/docs/contribution/releases/readiness.md
index 489f61fa29a..5cc1cd4f05c 100644
--- a/docs/contribution/releases/readiness.md
+++ b/docs/contribution/releases/readiness.md
@@ -23,16 +23,18 @@ The handle also holds a standing set of engineering members and the current and
The RC is the last point where finding a problem is cheap: nothing has shipped, and delaying costs a day, not a revert. The review runs before the RC build starts and answers one question - is there anything we know about that should stop this release?
+The RC build doesn't exist yet when the review runs, so it works from the latest beta and from everything reported since feature freeze. Each item is recorded as a comment on the RC sub-issue on GitHub: the evidence checked and the verdict.
+
The checklist covers four areas:
-* **Compatibility evidence.** The QIT compatibility regression sweep runs automatically against each prerelease and reports which extension versions the release would break. Introduced issues need a verdict, not just a look.
-* **Open findings.** Bug reports, testing threads, and monitoring alerts against the release each get a linked issue and a verdict per the [release decision matrix](/docs/contribution/releases/decision-matrix): release-blocking, fix in a point release, next release, or not a bug.
-* **Rollback path.** Who reverts, how, and what revert means for this version - answered before it's needed, not during an incident.
+* **Compatibility evidence.** The QIT compatibility regression sweep runs automatically against each prerelease and reports which extension versions the release would break. The review reads the latest beta's sweep. Introduced issues need a verdict, not just a look.
+* **Open findings.** Bug reports, testing threads, and monitoring alerts against the release each get a linked issue and a verdict per the [release decision matrix](/docs/contribution/releases/decision-matrix): release-blocking, fix in a point release, next release, or not a bug. The places to check are the comments on the cycle's pre-release notes post, the WordPress.org support forum, the canonical extensions testing post, and GitHub issues opened since feature freeze.
+* **Rollback path.** Who reverts, how, and what a revert would not undo for this version - database migrations, new settings - answered before it's needed, not during an incident.
* **Comms.** Changelog in shape, and a known-issues list when verdicts left something open.
-## Go/no-go (24-48 hours before stable)
+## Go/no-go (after RC staging, before the stable build)
-A deliberate decision to ship, made while there is still time to not ship. The release lead and the Product DRI confirm the readiness verdicts still hold and nothing blocking has appeared since the readiness review, then record the decision on the release sub-issue: **go**, **no-go**, or **go with conditions** - with names.
+A deliberate decision to ship, made while there is still time to not ship. It runs once the RC has finished its staging monitoring - holding it earlier would mean deciding before the RC has been seen on real sites. The release lead and the Product DRI confirm the readiness verdicts still hold, review the RC's sweep and staging thread, and note any fix merged after the RC and whether it ran on staging. Then they record the decision as a comment on the release sub-issue on GitHub: **go**, **no-go**, or **go with conditions** - with names.
Recorded decisions are the input for release retrospectives and future updates to these checklists.