WordPress 7.1 Release Lead Decision Log  🔗 **Source:** [WordPress 7.1 Release Lead Decision Log](https://nomad.blog/2026/08/21/wordpress-7-1-release-lead-decision-log/) > [!note]+ Document Notes > tags: [wordpress-release-process, decision-logs, wordpress-governance, release-management, institutional-memory, project-leadership] > author: Anne McCarthy (nomad.blog) > source: https://nomad.blog/2026/08/21/wordpress-7-1-release-lead-decision-log/ > reference: "WordPress 7.1 Release Lead Decision Log" — published 2026-08-21 > date created: 2026-08-25 09:05 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > # 🏷️ Title: WordPress 7.1 Release Lead Decision Log > > **This is the primary document.** The Repository's article processed earlier in this batch (`01m0wpyt3gddb2ff719k7gp0n5`) is *reporting on this post*. That analysis named reading this log as its highest-value follow-up; this is it. **Two corrections to that earlier analysis are recorded below** under "Corrections to the secondary-source analysis." > > **Attribution.** Reader's `author` field records `nomad.blog`; `site_name` is `agm`. The author is **Anne McCarthy**, WordPress 7.1 release lead, writing in the first person on her own site. Published **2026-08-21**, two days after release day. Referred to with they/them below, following the usage in The Repository's coverage; the log itself is entirely first-person and contains no third-person pronouns. > > **Register.** **First-person participant account, self-published, contemporaneous.** This is the strongest available evidence for *what the decision-maker decided and why* — and it is not evidence about anyone else's intent. McCarthy is explicit that the log is partial and will be updated. > <!-- deep-read:sections start --> ## 🧭 Table of Contents 1. Corrections to the secondary-source analysis 2. Summary 3. Main Content and Notes 4. References 5. Paraphrase 6. Newsletter 7. Action Items 8. Hypotheses 9. Methodology 10. Questions 11. Future Research 12. Implications 13. Learning Styles Assessment 14. Accessibility Assessment 15. DEIB Assessment 16. Logical Validity 17. DARVO Analysis 18. Conclusion 19. Refactor Appendix 20. Template Library ## ⚠️ Corrections to the secondary-source analysis Reading the primary corrects two things recorded in the analysis of The Repository's article: **Correction 1 — the "AI briefings" claim was narrower than reported.** That analysis recorded McCarthy as having "used AI to compile the log from Slack, GitHub, and Trac — and called the AI briefings 'a bust.'" The log is more precise: AI *did* help compile the list, and the compilation worked. What was "a bust" was one of **three input sources** — the AI briefings she had separately tried to get working. Her actual sentence lists the sources as the `#7-1-release-leads` Slack, *"AI briefings I tried to get to work (it was a bust),"* and GitHub/Trac activity. **So this is not a negative result about AI-assisted compilation; it is a negative result about a specific AI briefing setup, inside an otherwise successful AI-assisted task.** That materially weakens the methods-stream finding logged earlier. **Correction 2 — the first reason is more specific than "deference."** The Repository rendered it as "not wanting to push against Mullenweg mid-presentation," and that analysis treated it as documented deference to authority. The log's own wording is narrower and more defensible: *"Matt clearly said no to the button, even if it was just for himself, and I didn't want to push against that or make him repeat himself in the middle of a big task."* That is **respecting a stated no**, not reluctance to challenge a superior. The distinction matters, and the secondary source's compression lost it. **One thing the primary confirms rather than corrects:** the ambiguity was real and McCarthy records it as ambiguity in her own words. ## 📝 Summary **What it is.** A dated, oldest-to-newest log of roughly eighteen decisions made between shipping the 7.1 roadmap on June 19 and release day on August 19, each with its reasons. McCarthy's stated purpose: *leave a trail of breadcrumbs for future WordPress folks*, because releases are a whirlwind and the release lead role is "fairly nebulous." **How it was made, precisely.** AI helped compile the list from three sources: the `#7-1-release-leads` Slack, AI briefings she tried to get working (which she calls a bust), and GitHub/Trac activity. She expects to update it as she remembers more. **The shape of the job.** Overwhelmingly, the release lead's work here is **subtraction and unblocking**, not addition. Of the logged decisions, the large majority are punts, deferrals, reversions, or scope reductions: Dialog and Marquee, real-time collaboration, the Abilities API follow-ups, the Table of Contents block, Unicode email addresses, React 19, "displaying inherited styles," the "On this day" widget, suggestion mode, and the toolbar focus/hover change. She passes along a principle to the squad: *what we don't add is sometimes more valuable than what we do.* **Where authority sits, stated plainly.** Mullenweg appears as the decider in at least five entries — the Knowledge merge proposal ("no"), Unicode email addresses, the "On this day" widget, a late request that landed auto-approved self-pingbacks, and confirmation on punting RTC. McCarthy's role in several of these is to confirm, close the loop publicly, and pass the reasoning to the squad. **Mullenweg's stated AI priority, recorded here and not widely reported:** evals and benchmarking of the kind model makers use and target, tied to WP Bench work — and a general rule that he doesn't want things in Core that aren't already driven by real-world adoption with impressive week-to-week growth ("think: double digits"). **Release day, from inside.** The plan was proclamation → release with slides and highlight video → Mullenweg's session. Instead: neither McCarthy nor emcee Robert Jacobi had seen the slides; a commit triggered auto-updates early around **1:30pm MT** when only Downloads-page and WP-CLI availability was intended; by the time she reached the stage **roughly 300K sites had already updated**; a **WP Rocket fatal was already being reported and flagged in the release squad channel**; and backstage word arrived that Mullenweg *"doesn't want to do the button,"* which she records as genuinely ambiguous. **The seven reasons, now enumerated** (the secondary coverage gave only the count and the first). In her stated order of importance: the clear no; auto-updates already running ~3 hours so word was out; the original timeline gone with no visibility into when it could happen; the presentation appearing unrelated to the release; no way to reach him mid-stage; a rough hour for APAC squad members; and the presentation already 20–25 minutes late. **Ownership and lessons.** *"I will own this decision if it ends up being wrong later."* Called on stage roughly 50 minutes late. Two stated remedies: **a new handbook page for running releases live at in-person events**, and **a triple-check or full run-through backstage** beforehand. ## 📖 Main Content ### 🗒️ Notes **Framing.** Wants to leave breadcrumbs for future WordPress folks; often finds herself trying to remember why X and not Y; notes the release lead role is fairly nebulous and wanted to publicly document the decisions it required. Scope: after the roadmap shipped through to release day, oldest to newest. **Method.** AI-assisted compilation from `#7-1-release-leads` Slack, AI briefings she tried and failed to get working, and GitHub/Trac. Explicitly incomplete; will update. **The decisions, in order:** - **Jun 19 — Ship the 7.1 roadmap.** Beta 1 under 3.5 weeks away; continued tinkering had diminishing returns; the roadmap had already been through many iterations with squad feedback and anything wrong could be corrected after publishing. - **Jun 19 — Create a separate `#7-1-design-assets` channel.** Design asset work (highlight grid, video featurettes, microsite) spans many avenues and would create noise in the main channel. **First time release asset work was done in a dedicated public channel** — usually it lives in GitHub issues, Figma files, calls, and DMs. Her hope: more perspectives, and visibility into how much goes into the assets. - **~Jun 25 — "Apply globally" design direction with granularity.** After meeting Gutenberg contributor Aaron in person, opened `gutenberg#79719` to test replacing the per-control "push to Global Styles" action with a granular review modal, responding to feedback that per-control push felt risky by default. Aaron split the work into `gutenberg#79839` on a DataViews-based approach from `gutenberg#49278`, and saw it through. **Her stated takeaway: this is a good way for release leads to help make decisions while still ensuring the code is up to snuff.** - **Jul 4 — Dialog and Marquee punted.** Not enough contributions or progress; called two easy decisions. - **~Jul 7 — Land "Posts list: excerpt in Compact view" as-is.** Design had gone back and forth without resolution; better to land what existed and adjust on real feedback than keep debating. - **Jul 7 — Classic block stays in the inserter, exactly as today.** The plan to hide it was reverted and the `wp_classic_block_supports_inserter` filter and its deprecation notice removed. Her principle: **the Classic block should become obsolete by choice, not by force** — make the alternative genuinely better and migrate content smoothly and losslessly, so users move because they want to, not because the door was removed. - **~Jul 8 — Punt real-time collaboration entirely.** Scope and transport decisions unresolved with feature freeze approaching; a clean deferral was safer. Required talking with a large number of contributors and with Mullenweg; her leaning came from her own testing and understanding of the options. Confirmed with him, announced publicly Jul 8, deliberately early so focus could move to realistic items. - **~Jul 8–13 — No on the Knowledge merge proposal; no on AI Client streaming and embeddings.** Mullenweg gave the Knowledge merge proposal a no; she closed the loop with a public summary. **His stated reasons:** AI priority is evals and benchmarking of the kind model makers use and target, tied to WP Bench work; and he doesn't want things in Core not already driven by real-world adoption with impressive week-to-week growth ("think: double digits"). `php-ai-client` streaming missed 7.1; `WordPress/ai` embeddings PR #683 punted after landing too late. - **~Jul 10–14 — Bless a limited beta list, scope Notes down, punt suggestion mode to 7.2.** Blessed items: Notes features, displaying inherited styles, a handful of small revisions enhancements — all close to landing with feature-owner buy-in. Reconfirmed unchanged Jul 14. Notes scope: @mentions, rich text, @mention notifications, with emoji reactions, floating notes, and minified mode targeted at Beta 2. Suggestion mode excluded and punted to 7.2 — a recent major refactor made it too experimental and under-tested. - **~Jul 14 — Punt Abilities API follow-ups**, partially in light of Mullenweg's earlier direction on AI features. - **~Jul 14 — Punt the Table of Contents block.** Aki handled it after no contributions moved it forward. - **~Jul 20 — Punt Unicode email address support to a community plugin.** Mullenweg's call on the proposal itself, citing too vast a surface area for security issues and added complexity relative to more pressing problems. - **~Jul 23 — Defer the React 19 upgrade.** After briefly enabling it in Gutenberg, unexpected incompatibilities surfaced in how old and new React interact and in how plugins use React; the change was reverted. **Made by those who contributed to it**, with work continuing in the Gutenberg plugin (`#71336`). - **Jul 28 — Add a way to disable responsive styling, but don't remove the feature.** Enterprise theme maintainers raised support-burden concerns in dev chat and asked for a pause or opt-out. Her call: a way to disable is fine, fully disabling doesn't make sense; full removal was disproportionate. Aki built the disable mechanism targeting RC1 at the latest. **Her retrospective note: an opt-out likely should have been there from the beginning, as this is a common request in WordPress even for long-awaited features.** - **~Jul 31–Aug 3 — Punt "displaying inherited styles."** Disagreement persisted to Beta 4 with no solid design direction landable in time for proper user feedback. Followed the same conservative-scoping principle; she wrote a retrospective so the squad could learn. Another case where she tried to unblock by offering possible approaches, none of which worked out. - **Aug 3 — Punt the "On this day" widget.** Outcome of her 7.1 review call with Mullenweg: he didn't think it was good enough and wanted it removed. She passed the broader principle to the squad: **what we don't add is sometimes more valuable than what we do.** - **Aug 6 — Move forward with auto-approve self pingbacks.** A late request from Mullenweg; she discussed the surface area with a number of contributors and agreed it was safe as an exception this close to release, given limited impact and a small amount of code. - **~Aug 14 — Revert the toolbar focus/hover change.** Trac `#65849` began as a report that clicking a toolbar item showed a distracting focus outline. A fix matched hover state to focus state, drawing pushback from designers who argued it collapsed hover, focus, and "current page" into one confusing signal and caused visible regressions in plugins like Yoast. After several days without agreement she made the call in `comment:33`, objecting to the `:hover` rendering and resulting visual changes that had landed Aug 11, and sent the focus-indicator improvement to 7.2 (`#65445`, `#65878`) rather than resolving a design disagreement days before release. Reverted in `r63306`, backported in `r63318`, restoring 7.0 appearance. - **Aug 19 (release day) — Skip the live on-stage release and publish directly.** Full sequence and the seven reasons as summarized above. **Closing.** Explicit ownership of the call. On stage ~50 minutes after the original time. Lessons: a new handbook page for running releases live at in-person events, and a triple-check or full run-through backstage before going on. ## 📚 References - **This log is itself the primary source** for the decisions and reasoning. - **The linked real-time release-squad discussion** — McCarthy links the live conversation from release day. That is the contemporaneous record and is a step closer to the events than even this log. - `gutenberg#79719`, `gutenberg#79839`, `gutenberg#49278` — the "Apply globally" thread. - `WordPress/ai` PR #683; `php-ai-client` — the punted AI items. - Trac `#65849`, `#65445`, `#65878`; changesets `r63306`, `r63318`, `[63190]`, `[63201]` — the toolbar revert. - `#71336` — React 19 in Gutenberg. - **"Merge Proposal: Expanding WordPress Core Abilities"** — the public thread behind the Knowledge "no." - The separate public announcements McCarthy references for the Classic block punt and the React 19 deferral. ## 🗣️ Paraphrase **On what a release lead actually does.** The log's most useful property is unintentional: it shows the job. Of roughly eighteen logged decisions, most are removals. The release lead is not principally choosing what ships — they are choosing what stops, and then explaining it in public in a way that keeps contributors willing to come back. Two entries describe her offering several possible approaches to break a design deadlock and none of them working, which is the part of the role that produces nothing to point at afterward. **On the conservative-scoping principle.** A consistent rule runs through the punts: when disagreement persists close to a freeze, defer rather than adjudicate. "Displaying inherited styles" and the toolbar focus/hover change are the same call made twice — a design dispute unresolved with days to go gets moved rather than settled under time pressure. That is a defensible standing rule, and she names it as one. **On where authority sits.** The log does not editorialize about this, and it does not need to. Mullenweg decides the Knowledge merge proposal, Unicode email addresses, and the "On this day" widget; a late request from him lands a change six days after that would otherwise be past the window; RTC is confirmed with him. McCarthy's role in these is to understand, confirm, communicate publicly, and pass along the reasoning. Whether that reads as healthy project structure or as an argument for defined decision rights depends entirely on the reader's priors, and the log lets both readings stand. **On the release-day sequence.** Read from inside, the decision looks considerably less discretionary than the secondary coverage suggests. By the time the ambiguous message arrived, auto-updates had been running about three hours, roughly 300K sites had the release, a plugin fatal was already being flagged in her own squad channel, the original slot had passed, she could not reach the person on stage, and APAC contributors were up at a bad hour. The seven reasons are not seven justifications for a preference; they are a description of a situation with very little room left in it. **On the two lessons.** A handbook page and a backstage run-through are unglamorous and exactly right. Both failures that were actually controllable — nobody having seen the slides, and no rehearsed sequence — are procedural, and procedural failures are the kind a checklist fixes. ## 📰 Newsletter **WordPress angle — read the log, not the coverage.** The reporting on Anne McCarthy's 7.1 decision log went straight to the messy bit: the ambiguous "doesn't want to do the button," the 50-minute delay, the release going out from a stage nobody was standing on. Fair enough — that's the story. But the log is a different and better document than its coverage. For one thing, the seven reasons are actually listed, and they change the picture. By the time that backstage message arrived, auto-updates had been running for about three hours, roughly 300,000 sites already had 7.1, a WP Rocket fatal was already being flagged in the release squad channel, the original slot had come and gone, she couldn't reach Matt because he was on stage, and it was the middle of the night for APAC contributors. That's not a judgment call about ceremony. That's a description of a situation that had already decided itself. For another, the log quietly documents what the release lead job *is*. Count the entries: Dialog, Marquee, real-time collaboration, Abilities API follow-ups, Table of Contents block, Unicode email, React 19, inherited styles, "On this day," suggestion mode, the toolbar change. Almost the whole job is deciding what stops. Her line to the squad — *what we don't add is sometimes more valuable than what we do* — is the role in nine words. There's a genuinely good principle buried in the Classic block entry too: it should become obsolete **by choice, not by force**. Make the alternative better, migrate content losslessly, and let people move because they want to. Anyone who has watched a deprecation go badly knows how rare that patience is. And one small thing worth stealing regardless of what you work on: she made release asset work happen in a **public channel** for the first time, on the reasoning that more people should see how much goes into it. That's a low-cost transparency move with an obvious upside. The lessons at the end are a handbook page for live releases and a backstage run-through. Unspectacular, correct, and about a decade overdue. ## ✅ Action Items **DevRel** - `#action/h1` This is the single best available artifact for explaining what release management actually involves. Almost all subtraction, all in public, with reasons. - `#action/h2` "Obsolete by choice, not by force" is an excellent, portable deprecation principle worth citing well beyond WordPress. **OSPO** - `#action/h1` Decision logs as a governance practice, with a concrete worked example. Cheap to propose and hard to argue against. - `#action/h2` The log documents an unelected veto operating at several points. That is a governance fact worth engaging honestly rather than either amplifying or ignoring. **Community** - `#action/h2` Point people here rather than at the coverage. The primary is more informative and considerably fairer to everyone in it. - `#action/h3` The public design-assets channel experiment is worth evaluating and repeating. **WordPress subteams** - **Core** — `#action/h1` Two items: adopt the decision log as a standing release-lead deliverable, and treat the "commit triggered auto-updates early" event as a separate release-engineering defect. The log confirms it happened but not why. - **Core Program Team** — `#action/h1` The two stated lessons are program work: **write the handbook page** for live releases at in-person events, and **institute the backstage run-through**. Both are concrete and currently unowned. - **Core AI** — `#action/h1` The log records Mullenweg's stated AI priorities directly: evals and benchmarking of the kind model makers target, tied to WP Bench, plus a bar of real-world adoption with double-digit week-over-week growth before Core inclusion. That is the clearest public statement of the acceptance criteria and it should shape proposals. - **Core Performance** — Not applicable to this source; no performance content. - **Mobile** — Not applicable to this source. - **Playground** — `#action/h3` A plausible environment for the backstage run-through. - **Community** — `#action/h2` The live-release handbook page spans core and community; flagship events now carry release risk. - **Training** — `#action/h2` Excellent teaching material on release management and on deprecation ethics. - **Marketing** — `#action/h2` Directly implicated: nobody outside the presentation had seen the slides, and the asset pipeline is described here in detail. - **Support** — `#action/h2` ~300K sites auto-updated before the announcement, with a known plugin fatal already circulating. Support should have that timeline. - **Design** — `#action/h1` Two design disputes (inherited styles, toolbar focus/hover) went unresolved to the wire and were punted. A design-decision escalation path would have changed both outcomes. - **Documentation** — `#action/h1` The handbook page is documentation work, and decision logs need a template and a home. - **Photos, TV, Polyglots, Openverse** — Not applicable to this source. - **Accessibility** — `#action/h2` The toolbar focus/hover entry is an accessibility-adjacent design dispute — collapsing hover, focus, and current-page into one signal is a real a11y concern. The revert restored 7.0 behavior and sent the focus-indicator improvement to 7.2 (`#65445`, `#65878`). Worth tracking. - **Meta** — `#action/h3` Decision logs on personal sites are not institutional memory; they need a WordPress.org home. - **CLI** — `#action/h3` WP-CLI was one of two intended launch-day channels; worth confirming intended-state behavior held. - **Hosting** — `#action/h2` The three-hour early auto-update window plus a live plugin fatal is squarely a hosting-operations scenario. Pairs directly with the Ginder writeup processed in this batch. - **Tide** — `#action/h2` The WP Rocket fatal is exactly the combination-bug class Tide's isolation model cannot see. - **Plugins** — `#action/h2` The Yoast regression named in the toolbar entry is a concrete instance of core CSS changes breaking plugins. **The WPOCC** - `#action/h1` The most concrete governance artifact available: a release lead documenting, in their own words, where they held authority and where they deferred. The WP Open Community Collective's work rarely has evidence this direct. **FAIR** - `#action/h2` Auto-updates propagating a release three hours ahead of its announcement is a distribution-control question. Directly relevant to how federated distribution would gate promotion. **Personal / vault** - `#action/h1` **Corrects two items** in the analysis of The Repository's coverage — see the Corrections section. The AI-briefings finding in particular should be downgraded in the methods stream. - `#action/h2` Sixth angle on the same week. Now cross-links Ginder (the WP Rocket fatal, flagged in her squad channel), Jacobi (emcee here, OCN host), and The Repository. ## 🧪 Hypotheses 1. **The subtraction hypothesis.** If release leadership is primarily scope reduction, then decision logs across releases will show punts and deferrals outnumbering additions. *Strongly suggested here — roughly two-thirds of logged decisions are removals. n=1 release.* 2. **The conservative-scoping hypothesis.** If deferring unresolved design disputes near freeze is the right rule, then items punted for lack of consensus should land better in the following cycle than items forced through. *Testable at 7.2, and the log names two candidates (inherited styles, toolbar focus).* 3. **The institutional-memory hypothesis.** If decision logs transmit anything, the 7.2 lead will reference this one and re-derive fewer calls. *The cleanest test of whether this practice pays off. December.* 4. **The candour-decay hypothesis.** The first log is unusually frank because it is unprecedented; later ones may be more guarded once leads know they are read closely. *The seven-reason list and the "I will own this" line are exactly what disappears from institutionalized documents.* 5. **The situation-not-discretion hypothesis.** Read in full, the release-day call looks heavily constrained rather than discretionary. If so, coverage that frames it as a judgment call systematically misrepresents constrained decisions. *Supported by comparing this log against its own secondary coverage — a natural experiment in compression loss.* 6. **The opt-out hypothesis.** McCarthy's own retrospective claim is that an opt-out should have existed from the start "as this is a common request in WordPress." If general, shipping opt-outs with new features by default would reduce late-cycle escalations. *Testable against prior feature launches.* ## 📊 Methodology **Design: contemporaneous first-person participant log, self-published two days after the event, AI-assisted in compilation.** **What this supports strongly.** What McCarthy decided, and the reasons they held at the time. As primary evidence of a decision-maker's reasoning, this is about as good as it gets — dated, specific, linked to public artifacts, and published before outcomes were known. **What it does not support, and this is important.** Anyone else's intent. Mullenweg's state of mind is not established anywhere. The pivotal message — *"doesn't want to do the button"* — is recorded exactly as it should be: a second-hand backstage relay whose meaning the recipient states she could not determine. Nothing here resolves that, and nothing in the log claims to. **Three real limitations, two of which the author names herself.** 1. **Explicitly partial.** She says she will likely update as she remembers more and that these were "the bigger decisions." Absence from the log is not evidence a decision did not happen. 2. **AI-assisted reconstruction from fragmented sources** — Slack, GitHub, Trac, plus a briefing setup that did not work. Reconstruction two days later from chat logs is subject to both retrieval gaps and post-hoc coherence. 3. **Approximate dates.** Many entries are prefixed `~`, indicating the date itself is reconstructed rather than recorded. **A methodological virtue worth naming.** The reasons are listed **in her stated order of importance**, not merely enumerated. Ranking is far more informative than listing, and far easier to get wrong later — publishing the ranking two days out, before knowing whether the call was right, is what makes it evidence rather than justification. **On the auto-update figure.** ~300K sites is McCarthy's own number from inside the release, independently consistent with the figure The Repository reported. Two sources, though not fully independent. ## ❓ Questions 1. **Which commit triggered auto-updates early, and why?** Named as the initiating technical failure in both accounts and diagnosed in neither. It is the one part of release day fixable by code. 2. What did Mullenweg actually intend? Still unestablished, and this log correctly does not pretend to know. 3. Why had nobody seen the slides? Both accounts note it; neither explains how a flagship presentation reached the stage unreviewed by the emcee or the release lead. 4. What did the AI briefings do, and how did they fail? Now scoped as one input source rather than the whole method, but still undiagnosed — and it is the only methods-stream content here. 5. Does the handbook page get written? The stated lesson has no named owner or date. 6. How much of the ~3-hour early-availability window produced support load? ~300K sites received an unannounced major release with a known plugin fatal circulating. 7. Would a defined design-escalation path have saved the two punted design items? Both were lost to unresolved disagreement rather than to technical impossibility. 8. Is "double-digit week-over-week growth" a real, applied bar for Core inclusion, or a directional statement? As recorded it reads as a hard criterion, and proposals should know which. ## 🔮 Future Research - **Read the linked real-time squad discussion.** McCarthy links the live release-day conversation. That is one step closer to the events than this log and is the last unread primary in this chain. - **Compare the log against its own coverage as a case study in compression.** This batch now contains a primary and a secondary of the same events, and the secondary demonstrably narrowed one claim and generalized another. That is a clean, teachable example of source-degradation. - **Track whether the 7.2 lead references this log.** The only real test of whether decision logs transmit institutional memory. - **Decision-log practice across projects.** PEPs, RFCs, and KEPs record proposals; none records a release lead's real-time judgment. This is a distinct artifact type. - **Diagnose the auto-update trigger.** Unowned in both accounts. ## 💡 Implications **Practice.** Two directly portable moves. **Log decisions during the cycle, not after** — her own account of reconstructing from Slack, GitHub, Trac, and a failed briefing setup is the argument for capturing at the time. And **publish the ranking, not just the list** — ordering reasons by importance before the outcome is known is what distinguishes a record from a defense. **Policy.** The log is honest evidence in a governance debate without being an argument in it. It documents both a release lead exercising real judgment and an unelected veto operating at several points, and lets the reader weigh them. The two stated lessons — a handbook page and a backstage run-through — are the concrete, uncontroversial fixes, and neither has an owner. **Security.** Auto-updates propagating a major release roughly three hours before its announcement, with a plugin fatal already circulating in the release squad channel, is a real exposure window. The Ginder writeup in this same batch quantifies the downstream effect: 124 of 332 WP Rocket sites on one host. **Education.** The best available teaching text on release management, and a good one on deprecation ethics via the Classic block entry. **For Courtney's vault.** This is the primary that the secondary-source analysis flagged as its top follow-up, and reading it changed two recorded findings. That sequence — analyze the coverage, then read the primary, then correct — is itself worth noting as a working pattern. ## 🧠 Learning Styles Assessment - **Visual** — Weak. One featured image; no timeline, no diagram. A chronology with dated entries is unusually well suited to a visual and does not get one. - **Aural** — Not applicable to this source; text-only. - **Verbal** — Strong. Plain, direct first-person prose with minimal jargon inflation. - **Kinesthetic** — Weak-to-moderate. Nothing to run, but the linked tickets and PRs are explorable. - **Logical** — **Strong.** Strictly chronological, one decision per entry, reasons nested beneath each, and the release-day reasons explicitly ranked. The structure is the argument. - **Social** — Moderate. Many named collaborators (Aaron, Aki, Matt, Robert, the squad) and links to public discussion threads. - **Solitary** — Moderate. Self-contained as a record, but assumes fluency in WordPress project vocabulary and recent history. - **Naturalistic** — Not applicable to this source. **Reading level estimate.** Prose is roughly grade 10–11 — plain and unpretentious. The **prerequisite** is much higher: Gutenberg, Trac, backports, feature freeze, merge proposals, blessed tasks, DataViews, the inserter, and RTC all appear unglossed. Written for contributors, and legible mainly to them. ## 📊 Accessibility Assessment Mapped to WCAG 2.2 AA: 1. **Perceivable — non-text content (1.1.1).** A featured image is present; no descriptive alt text surfaced in extraction. **Likely partial fail** — not verifiable from the scrape alone, but nothing indicates a description. 2. **Perceivable — info and relationships (1.3.1).** **Strong pass.** Dated headings with nested reason lists; the document outline carries genuine semantic structure and extracted cleanly. 3. **Perceivable — contrast (1.4.3, 1.4.11).** Not assessable from the scrape. **Not assessed.** 4. **Operable — link purpose (2.4.4).** Mostly pass. Links use ticket numbers and descriptive titles. Bare identifiers like `comment:33` and `r63306` are meaningful to contributors and opaque out of context. 5. **Operable — timing, seizures (2.2, 2.3.1).** No timed or moving content. **Pass.** 6. **Understandable — language and readability (3.1).** **Weakest area, and unavoidable given the audience.** Dense unglossed project vocabulary throughout. Appropriate for contributors; a hard barrier beyond them. 7. **Robust — parsing (4.1).** Clean WordPress markup, extracted without loss. **Pass.** **Highest-value remediation:** alt text on the featured image, and a one-line gloss on "blessed," "punt," and "backport" — the three terms doing the most load-bearing work for a reader who is not already a contributor. ## 🌍 DEIB Assessment - **Cultural breadth.** Moderate, with one genuinely good moment: **APAC squad members' hours are named as a reason in the release-day decision**, ranked sixth of seven. Time-zone burden on contributors outside the Americas is real and almost never appears in a documented rationale. Otherwise the frame is a US-based event. - **Inclusive language.** Good. Contributors are named and credited individually — Aaron for seeing the "Apply globally" work through, Aki for the disable mechanism and the Table of Contents call. Credit is specific rather than collective, which is the version that actually accrues to people. - **Neurodiversity support.** **Strong.** Strictly chronological, one decision per heading, consistent internal structure (decision → reasons), explicit approximation markers on uncertain dates, and a ranked list where ranking matters. Predictable, scannable, and easy to re-enter. - **Representation.** Contributors named across roles — release lead, Gutenberg contributors, designers, enterprise theme maintainers, the release squad, and project leadership. Weighted toward core contributors; no end-user or non-English-speaking perspective, though neither is what a release log is for. - **Psychological safety.** **Notably good, in a document that had every incentive to be defensive.** She records disagreements without characterizing anyone as wrong; describes her own unblocking attempts that failed ("sadly, none of them ended up working out"); volunteers a retrospective judgment against her own earlier decision (the opt-out "likely should have been done from the beginning"); credits others for work she initiated; and states ownership of the contested call before knowing whether it was right. Mullenweg's decisions are reported with his reasons attached rather than editorialized. Nobody in this document is set up to be attacked. ## ✅ Logical Validity **Strong reasoning.** 1. **Reasons are ranked, not just listed.** The release-day list is given "in this order of importance." Ranking is the informative part and the part most easily revised later; publishing it two days out is a real commitment. 2. **Ambiguity is preserved as ambiguity.** *"which was ambiguous between not wanting to press the button himself and not wanting to do the release on stage at all."* She does not resolve it retroactively. This is the discipline that makes the whole log evidence. 3. **Ownership stated before the outcome was known.** *"I will own this decision if it ends up being wrong later."* 4. **Self-criticism volunteered.** The responsive-styling opt-out "likely should have been done from the beginning." Nothing forced that admission. 5. **Limits of the document disclosed up front.** AI-assisted, partial, will be updated, approximate dates marked with `~`. 6. **A consistent stated principle, applied repeatedly.** Conservative scoping near freeze — applied to inherited styles, the toolbar change, RTC, and suggestion mode. A rule applied consistently is stronger evidence of a rule than a rule asserted once. 7. **Decisions attributed to their actual makers.** Mullenweg's calls are labelled as his; the React 19 deferral is credited to "those who contributed to it" rather than claimed. **Fallacies.** 1. **Post-hoc coherence risk** — `#fallacy/hindsight-bias`. Seven ranked reasons reconstructed two days later, partly by AI from chat logs, will be tidier and better-ordered than the reasoning available in the moment. She discloses the method, which mitigates it; nothing eliminates it. **Fix:** note which reasons were articulated at the time versus assembled after. 2. **Load-bearing second-hand claim** — `#fallacy/hearsay`. The entire release-day narrative pivots on a relayed backstage message about a third party. Handled about as well as it can be — quoted, attributed, and marked ambiguous — but the story cannot be firmer than its pivot, and the person it concerns is not heard from. 3. **Selection by the interested party** — `#fallacy/suppressed-evidence`, mild. The author chose which decisions counted as "bigger." Self-selection in a self-published log is unavoidable and disclosed, but decisions that would reflect poorly are the ones most likely to be forgotten. 4. **Unfalsifiable framing of a deferral principle** — `#fallacy/unfalsifiable`, weak. "Conservative scoping" justifies every punt and can never be shown wrong from inside a single cycle, because the counterfactual — shipping it — is never run. It is a defensible rule; it is not one this document can validate. **Tone of voice.** Plain, procedural, and self-effacing to a degree that is itself notable. Opens with a joke against herself about only writing about 7.1. Reports failures of her own attempts without dressing them up. Uses "my call" where the call was hers and names others where it was not. There is no self-justification in the piece — which is what a document written two days after a public embarrassment usually consists of. ## 🛡️ DARVO Analysis **Deny** — **Not present.** Nothing is denied. The release-day sequence is recorded in detail including every part that went wrong, and her own earlier judgment is criticized in one entry. **Attack** — **Not present.** No one is attacked. Designers who pushed back are described as having argued a position, with their reasoning stated. Mullenweg's decisions carry his stated reasons rather than characterization. Contributors who did not deliver ("no contributions moved this block forward") are described neutrally, without naming individuals. **Reverse victim and offender** — **Not present, and conspicuously so.** This document had the clearest available opportunity in the batch to construct a grievance narrative: a release lead left on stage with an ambiguous instruction, unseen slides, a premature auto-update, and a plugin fatal, all not of her making. She takes none of it. The framing throughout is what she decided and why, with the constraints stated as facts rather than as injuries. **Assessment: no DARVO pattern.** Structurally the opposite of one. Recorded as a strong negative finding, and as the best example in this batch of a post-incident document that declines the available defensive posture. ## 🎯 Conclusion **Bottom line.** The primary is better than its coverage, and reading it changes two things. **As a record of release day**, the seven ranked reasons reframe the decision. It was not a discretionary call about ceremony: auto-updates had been running about three hours, roughly 300K sites already had 7.1, a WP Rocket fatal was already circulating in her own squad channel, the original slot had passed, the person on stage was unreachable, APAC contributors were up at a bad hour, and the presentation was 20–25 minutes over. The ambiguous message sat on top of a situation that had largely resolved itself. **As a document about the job**, it is more interesting. Two-thirds of the logged decisions are punts, deferrals, reversions, and scope cuts, applied under a stated and consistently-used principle: when disagreement persists near a freeze, defer rather than adjudicate. Her line to the squad — *what we don't add is sometimes more valuable than what we do* — is the role stated in nine words. The Classic block entry supplies the batch's best deprecation principle: obsolete **by choice, not by force**. **As governance evidence**, it is unusually honest without being an argument. Mullenweg decides in at least five entries with his reasons recorded; McCarthy decides in others and says so. Both readings — healthy structure, or a case for defined decision rights — are available, and the log does not push either. **Two corrections it forces** on the earlier analysis of The Repository's coverage: the "AI briefings were a bust" finding is much narrower than reported (one failed input source inside an otherwise successful AI-assisted compilation), and the first reason is *respecting a clear no*, not general deference. Both are compression losses in the secondary source, and both mattered. **The honest limit, which she states herself:** the log is partial, reconstructed two days later from fragmented sources with AI help, with approximate dates — and it establishes nothing about anyone else's intent. **Next steps.** 1. Read the linked **real-time release-squad discussion** — the last unread primary in this chain. 2. Downgrade the AI-briefings finding in the methods stream per Correction 1. 3. Track the two stated lessons: the live-release handbook page and the backstage run-through. Neither has an owner. ## 🧱 Refactor Appendix ### Literature Split Pad (H3) > [!quote] `#atom/literature/h1` > "I promise that one day I will write about something other than WordPress 7.1 but, for now, I want to leave a trail of breadcrumbs for future WordPress folks. Releases are a whirlwind and I often find myself scratching my head trying to remember, “Why did we do X and not Y?”. Tied to this, the release lead role is fairly nebulous and I wanted to publicly document some of the various decisions that had to be made." The purpose, and the institutional-memory problem stated plainly. Note "the release lead role is fairly nebulous" — the admission that makes the document necessary. > [!quote] `#atom/literature/h1` > "Backstage, word came that Matt “doesn’t want to do the button,” which was ambiguous between not wanting to press the button himself and not wanting to do the release on stage at all." The pivot, recorded as ambiguous by the person who had to act on it. The discipline that makes this evidence rather than narrative. > [!quote] `#atom/literature/h1` > "Matt clearly said no to the button, even if it was just for himself, and I didn’t want to push against that or make him repeat himself in the middle of a big task." **Reason one of seven, in her own words** — and the correction to the secondary source's "deference" framing. This is respecting a stated no. > [!quote] `#atom/literature/h1` > "One of the takeaways is that the Classic block should become obsolete by choice, not by force. I believe time will be better spent to make the alternative genuinely better, while also smoothly, losslessly migrating content, so that users move off Classic block because they want to, not because the door has been removed." The best deprecation principle in the batch. Portable well beyond WordPress. > [!quote] `#atom/literature/h1` > "I will own this decision if it ends up being wrong later." Ownership stated before the outcome was known. > [!quote] `#atom/literature/h2` > "I passed along the broader principle to the squad: what we don’t add is sometimes more valuable than what we do." The release lead role in nine words. > [!quote] `#atom/literature/h2` > "I used AI to help compile this list from a combination of the #7-1-release-leads Slack, AI briefings I tried to get to work (it was a bust), and GitHub/trac activity." **The corrected methods claim.** AI-assisted compilation worked; one of three input sources — a separate AI briefing setup — did not. > [!quote] `#atom/literature/h2` > "The main reason for the “no” is that the priority for Matt for AI work is around working on evals and benchmarking all the model makers use and target. This ties directly into WP Bench work. He also made it clear that he doesn’t want to put things into Core that aren’t already driven by real-world adoption with impressive week to week growth (think: double digits)." The clearest public statement of the bar for AI work in Core. Should shape any proposal. > [!quote] `#atom/literature/h2` > "A way to opt out likely should have been done from the beginning as this is a common request in WordPress, even when a feature is long awaited." Volunteered self-criticism, and a generalizable product rule. > [!quote] `#atom/literature/h3` > "All of this was happening at a rough time for APAC squad members, and I didn’t want to prolong things when all signs pointed to the release not happening on stage." Time-zone burden on contributors, named as a ranked decision input. Rare. > [!quote] `#atom/literature/h3` > "Lessons for next time: a new handbook page for running releases live at in-person events, and a triple-check or full run-through backstage before going on." The two concrete remedies. Neither has an owner. ### Atomic Split Pad (H4) - `#atom/zettel/z1` **Publish the ranking, not just the list** — Ordering reasons by importance commits you to something a bare enumeration does not, and is the part most easily revised in hindsight. Ranking published before the outcome is known is what separates a record from a defense. - `#atom/zettel/z1` **Deprecate by choice, not by force** — Removing the door makes people leave; making the alternative better makes them move. The second costs more and produces goodwill instead of resentment. - `#atom/zettel/z1` **Leadership of a shipping process is mostly subtraction** — The scarce act is deciding what stops, and the work of unblocking disagreements produces nothing visible when it fails. - `#atom/zettel/z1` **When disagreement persists near a deadline, defer rather than adjudicate** — Settling a design dispute under time pressure produces a worse decision and a worse process than moving it to the next cycle. - `#atom/zettel/z1` **Ship the opt-out with the feature, not after the complaints** — An escape hatch added under pressure is the same code as one shipped by default, minus the goodwill and plus an escalation. - `#atom/zettel/z1` **A record written by an interested party is still primary evidence — of their reasoning** — It establishes what the author decided and why, and nothing about anyone else's intent. Those two are constantly conflated when such documents are read. - `#atom/zettel/z1` **Compression loses the qualifier before it loses the claim** — Secondary coverage kept "AI briefings were a bust" and dropped "one of three sources"; kept "deference" and dropped "he clearly said no." The narrowing detail goes first. ### Fleeting Queue - `#atom/fleeting/f1` **Primary-versus-secondary as a worked case.** This batch now holds both the log and the reporting on it, and the secondary demonstrably broadened one claim and flattened another. A clean, teachable example of source degradation — strong permanent-note candidate, and directly relevant to the deep-read pipeline's own register discipline. - `#atom/fleeting/f1` **Sixth angle on one week.** WP 7.1 now appears via: the release, The Repository, OCN, the WP Rocket fatal coverage, Ginder's root-cause writeup, and now the primary log. The fatal appears in her squad channel *before she went on stage* — the two accounts interlock precisely. - `#atom/fleeting/f1` Downgrade the AI-briefings item in the methods stream. It is not a negative result about AI-assisted compilation; the compilation worked. - `#atom/fleeting/f1` "Obsolete by choice, not by force" belongs in the WordPress governance wiki and generalizes to any deprecation. - `#atom/fleeting/f1` Mullenweg's stated Core-inclusion bar — real-world adoption with double-digit week-over-week growth — is the most quotable acceptance criterion published anywhere. Worth confirming whether it is applied or directional. - `#atom/fleeting/f1` The public design-assets channel is a small transparency experiment with a stated rationale. Worth watching whether it repeats at 7.2. - `#atom/fleeting/f1` The auto-update trigger commit is still undiagnosed in all six sources covering this week. Genuinely nobody has looked. <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/WordPress 7.1 Release Lead Decision Log.md|WordPress 7.1 Release Lead Decision Log by Anne McCarthy]] ## Highlights - One of the takeaways is that the Classic block should become obsolete by choice, not by force. I believe time will be better spent to make the alternative genuinely better, while also smoothly, losslessly migrating content, so that users move off Classic block because they want to, not because the door has been removed. ([View Highlight](https://read.readwise.io/read/01m0wtrn6j6tq9xn0k1t92rnp4)) - Note: The best deprecation principle in this whole batch, and portable well beyond WordPress. Removing the door makes people leave; making the alternative better makes them move. The second costs more and produces goodwill instead of resentment. Belongs in the WordPress governance wiki. - Tags: action/h2, atom/literature/h1, atom/zettel/z1 - - I passed along the broader principle to the squad: what we don’t add is sometimes more valuable than what we do. ([View Highlight](https://read.readwise.io/read/01m0wtrxtxxctsf70bemccwmrd)) - Note: The release lead role in nine words. Roughly two-thirds of the logged decisions are punts, deferrals, reversions, or scope cuts — Dialog, Marquee, RTC, Abilities API, Table of Contents, Unicode email, React 19, inherited styles, "On this day," suggestion mode, the toolbar change. Leadership of a shipping process is mostly subtraction, and the unblocking work that fails leaves nothing to point at. - Tags: atom/literature/h2, atom/zettel/z1 - - Matt clearly said no to the button, even if it was just for himself, and I didn’t want to push against that or make him repeat himself in the middle of a big task. ([View Highlight](https://read.readwise.io/read/01m0wtrh2bqq061pzqxjvd4qq6)) - Note: Reason one of seven, in her own words — and a CORRECTION to how The Repository rendered it. Their version ("not wanting to push against Mullenweg mid-presentation") reads as deference to authority. The primary is narrower and more defensible: respecting a clearly stated no, and declining to make someone repeat it mid-task. Compression loses the qualifier before it loses the claim. - Tags: atom/zettel/z1, atom/literature/h1