# WordPress 7.1 Release Candidate Phase > [!question] Lingering Questions > - How long did the branch delay actually last, and did it measurably protect the concurrent GitHub Actions work it was tied to? > - Were translators actually blocked in practice by the branch-timing dependency, or only in a way that never mattered because the branch landed quickly? > [!tip] Article Ideas > - Turn the field guide's shipped/deferred split and this post's RC policy into a reusable one-page "what belongs in a release milestone" checklist for contributor triage. #articleseed > [!link] Cross Reference > - [[3. Resources/Literature Notes/WordPress 7.1 Field Guide]] — the scope document for the same release this RC-phase post governs. > - [[3. Resources/MOCs/Open Source Governance MOC]] > [!quote] Vocabulary > - **Double sign-off** — the RC-phase rule requiring two Core committers to approve trunk commits (test-suite commits exempted) until the release branch exists. > - **Hard string freeze** — the point at which no new translatable strings may be added except critical, specifically tagged exceptions. ## Bib capsule Aaron Jorbin, "WordPress 7.1 Release Candidate Phase," Make WordPress Core, August 5, 2026. ## Author's thesis Entering Release Candidate status converts WordPress Core's normal commit process into a temporary, tighter governance state — double sign-off on trunk, hard string freeze, and a milestone narrowed to regressions and test-suite work — and this post exists to make those temporary rules legible to committers, translators, and non-committing contributors alike. ## Key arguments (≤3) 1. **Double sign-off is a shared-risk gate, not general suspicion.** Until the 7.1 branch exists, trunk commits need two Core committer approvals (test-suite commits exempted), which keeps verification work moving while raising the bar on behavior-changing commits specifically. 2. **String freeze is gated by both policy and infrastructure timing.** Hard freeze begins at RC1, but Polyglots can't fully start translation work until the version branch itself exists — a reminder that release "phases" are sometimes blocked on tooling as much as on rules. 3. **A narrow milestone is itself a contributor-education tool.** Restricting the 7.1 milestone to regressions and test-suite expansion gives triagers ("does this belong now, or does it wait for 7.2?") a simple yes/no rule instead of a judgment call. ## Claim atoms ### Double sign-off turns RC into a shared-risk gate - Claim: A temporary two-approver requirement on trunk, exempting only test-suite commits, converts general commit review into a specific pre-release risk control. - Evidence: The RC-phase policy explicitly names the double sign-off requirement and its test-suite exemption. - Candidate note: [[A Release Milestone Is Contributor Triage Training]] (below — the two claims fold into one durable note about process-as-education) ### Milestone scope is a contributor education tool - Claim: Restricting a release milestone to a narrow, checkable rule (regressions + test expansion only) does double duty as governance and as a teaching artifact for what "release-ready" work looks like. - Evidence: The post's framing of the 7.1 milestone as a triage rule for contributors, not just an internal team convention. - Candidate note: [[A Release Milestone Is Contributor Triage Training]] ## Permanent candidates - **A release milestone is contributor triage training** — combines the double-sign-off and milestone-scope observations into one atomic claim about release policy doubling as an onboarding/education artifact. Promote. ## Processing checklist - [x] Checked for existing Literature Note — none found - [x] Checked existing Permanent Notes for overlap — none found on RC-phase-as-education specifically - [x] Connected into [[3. Resources/MOCs/Open Source Governance MOC]] ## Links - [[3. Resources/MOCs/Open Source Governance MOC]] — release-phase governance is a direct, concrete instance of open-source process design