Why WordPress 7.1 Will Improve Your Workflow  🔗 **Source:** [Why WordPress 7.1 Will Improve Your Workflow](https://www.youtube.com/watch?v=lR17090NeGA) > [!note]+ Document Notes > tags: [wordpress-7-1, release-management, responsive-styling, collaborative-editing, client-side-media, block-states, backwards-compatibility] > author: Eric Karkovack > source: The WP Minute > reference: https://www.youtube.com/watch?v=lR17090NeGA > date created: 2026-08-01 10:15 > > > [!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: Why WordPress 7.1 Will Improve Your Workflow > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [The WP Minute](https://thewpminute.com/) — publisher; newsletter and member Slack - [WordPress.org News](https://wordpress.org/news/) — where the 7.1 beta announcements land - [WordPress Playground](https://playground.wordpress.net/) — how the release lead tests trunk daily - [Make/Core](https://make.wordpress.org/core/) — home of the phase 3 collaborative-editing research summary ## 📝 Summary - **What happened.** Eric Karkovack interviews Anne McCarthy, release lead for WordPress 7.1, roughly a week after Beta 1. The conversation is half feature demo, half candid account of what it is like to hold the final-call role for the first time, and it is unusually forthcoming about what did *not* ship and why. - **Why it matters.** Two decisions are more consequential than any feature. The classic block's removal was **paused** after usage stats showed it too heavily used, and **collaborative editing was pulled** on the release lead's own recommendation. Both are cases of WordPress choosing not to ship on schedule, which is the harder call and the one most releases don't document. - **Key stakeholders.** Anne McCarthy (release lead); Matt Mullenweg and Matías Ventura (agreed to pull collaborative editing); Adam Silverstein, Andrew Serong, and Pascal Birchler (client-side media); Scott Riley (on-this-day design); Amy and Justin Tadlock (collaborative-editing outreach); WordPress VIP (contributed to and uses collaborative editing); theme and plugin developers gaining an icon-registration API. - **Risks and tradeoffs.** Responsive styling ships with an unresolved UX debate — whether it should be always-on, and the genuinely confusing fact that it captures *style* changes but not *layout* changes. McCarthy flags this as needing iteration rather than presenting it as finished. - **Bottom line.** 7.1 is framed as a "landing" release where features shipped across 6.9, 7.0, and 7.1 converge into coherent responsive control. The more durable story is a release lead deliberately lowering the temperature after 7.0, and treating "don't ship it yet" as a legitimate outcome. ## 📖 Main Content **Responsive styling, and why it's a convergence rather than a feature.** The headline capability is that you can now style blocks per-viewport rather than merely preview them. McCarthy's framing is explicitly cross-release: 6.9 introduced show/hide for blocks, 7.0 added show/hide by screen size, and 7.1 adds actual per-viewport styling plus a custom navigation overlay and theme.json viewport customization. Her worked example on her own site is concrete — larger text on mobile, an entire image column hidden — and her point is that people "fixate on just one release when in truth a lot of the times we're shipping things in different releases across them." The underlying mechanism is **block states**, which she compares to a similar concept in Figma: combining attributes to determine how a block displays. The technical unlock was **pseudo-state styling** (hover styling for the button block), which also lands in 7.1. Her account of how this happened is the most interesting process detail in the interview — pseudo-state styling landed first, and only then did the UX for responsive styling become clear, at which point developers noticed the pattern could generalize. She describes this as WordPress converging on a solution rather than designing it up front. Two honest caveats accompany it. First, an unresolved UX debate: should responsive styling be always-on? She reports someone arguing yes and says plainly that she disagrees, because there are times you want to make a change without thinking about whether it applies everywhere. Second, and more likely to generate support tickets, the feature "takes style changes, but it doesn't take layout changes" — deleting a block while in mobile view deletes it everywhere. She names this as confusing and expects iteration. The API-design consideration is worth noting: with block states multiplying, the team spent significant effort on what the API shape should be so it remains "easily understood and readable" — and she explicitly includes AI as a consumer of that readability alongside humans. **The classic block reversal.** The plan was that new installs would not have the classic block. It was paused. The mechanism was product stats showing it was simply too used, prompted by Mullenweg noticing a deprecation notice while editing a friend's site. McCarthy describes the move as "flipping the question on its head" — instead of asking how to remove it, asking why people still use it and what would bridge the gap. She generalizes this into a recurring release tension between pushing forward and honoring backwards compatibility, and connects it to a user-experience argument: familiarity and ease of use matter more, not less, "especially in the age of AI." **Collaborative editing, pulled deliberately.** The most substantive segment. Progress exists, but three things converged against shipping. First, research: McCarthy's earlier phase 3 work interviewed roughly 25 organizations of varying sizes (summary public on Make/Core) and established that real-world usage — walking away from a draft, going to lunch, coming back — is what's needed, not synthetic load testing. Second, a mid-release architectural pivot: rather than shipping HTTP polling as a works-everywhere default, the idea was to ship *primitives* so hosts and plugins could bring their own transport. That triggered what she calls philosophical developer debates. Third, and most interesting, a product-risk argument. She notes that people carry a strong Google Docs connotation into the phrase "collaborative editing," and that shipping something that doesn't meet that expectation risks leaving a bad taste. Her deeper point is that the contexts differ in kind: writing in a Google Doc is insulated from publication, whereas WP Admin has the publish button right there. Large organizations told her they face real legal exposure if they cannot track who wrote what. Her conclusion is that collaborative editing needs surrounding workflow safeguards, not just the editing capability. She told Mullenweg and Ventura she didn't think they should ship it; they agreed. **Client-side media, the invisible half.** Framed as "more format support, better performant, more reliable" and explicitly described as foundational rather than noticeable — the background work that makes uploads feel easy. Punted from 7.0, landing in 7.1: HEIC (iPhone) photo support and MP4↔GIF conversion. On top of it sit three visible improvements: attaching media to a post and then pulling it into a gallery via "use attached images"; a modernized media cropper with flip support, which she says removes her habit of pre-editing photos before upload; and inline notes — highlight a sentence, rich text, @mentions, with notifications targeted before Beta 2. **Quality-of-life changes.** The omnibar is a persistent toolbar in the site editor, requested by Mullenweg because users landed there and couldn't find their way back — "great to be immersive, but not so much so that you feel trapped." Command palette gains recently-used and context-aware suggestions. A new site identity section brings settings that previously required the theme customizer into the modern flow. Posts without titles now show an excerpt, which came from Dave Winer's feedback that he writes untitled posts and couldn't identify them in the list. The admin color scheme now applies in the site editor. The media library gains optional infinite scroll. An "on this day" dashboard widget arrives, designed by Scott Riley (Coffee to Code) — McCarthy connects it to her own five-year journal habit and frames it as drawing people back to the dashboard "in a bit more of an emotional way." Finally, plugin and theme authors can now register custom icons for the icon block, closing a gap left when the icon block landed in 7.0 without third-party registration. **The release-lead account.** McCarthy has served on release squads in test, coordination, and documentation roles, but describes final-call authority as different in kind — "your voice carries a lot of weight," requiring restraint about how much she weighs in on design discussions. Her stated goal for 7.1 is explicitly reactive to 7.0: "bring the temperature down, make it predictable, get ahead of things as early as possible." She also found the role almost entirely undocumented, locating only a short paragraph from Andrew Nacin around WordPress 4.2/4.3, and has made documenting it a personal goal. **Uncertainties and contested claims.** The stats driving the classic-block reversal are referenced but not shown. The responsive-styling UX is openly unsettled. The Playground bug she hits live is unresolved on air. Collaborative editing has no new timeline. And the interview is entirely from the release lead's perspective — no dissenting contributor voice is present, which matters most for the pulled features. ## 🗒️ Notes #### ⏱️ [00:00](https://www.youtube.com/watch?v=lR17090NeGA?t=0) Setup - Eric Karkovack introduces Anne McCarthy as 7.1 release lead. Beta 1 has been out roughly a week. - Framing from the 7.0 product review with Mullenweg: when people update, "he wants them to feel it." McCarthy applies that as a design goal for 7.1. #### ⏱️ [02:30](https://www.youtube.com/watch?v=lR17090NeGA?t=150) First time holding the final call - Prior release-squad experience in test, coordinator, and documentation roles; involved in most releases somehow. - The difference is decision authority — previously "you could go to someone else to help make the decision." Now her voice carries weight, and she describes consciously restraining her own verbosity in design discussions so as not to over-guide. - Uses a soccer metaphor: it feels different to be "on the starting 11." #### ⏱️ [04:10](https://www.youtube.com/watch?v=lR17090NeGA?t=250) Two squad calls, and first-timers - Ran two release-squad calls to cover a wide time-zone spread. - Notes that some members are on their first release squad and calls that "a precious important moment in a contributor's journey" — setting the tone is part of the role. #### ⏱️ [05:00](https://www.youtube.com/watch?v=lR17090NeGA?t=300) Bringing the temperature down - Explicit contrast with 7.0: "no one wants to have what happened with 7.0 happen again," while acknowledging why space was given to real-time collaboration. - Stated goals: predictable, get ahead of things early, go smoothly. #### ⏱️ [06:40](https://www.youtube.com/watch?v=lR17090NeGA?t=400) The documentation gap - Found almost no documentation for the release-lead role — a short paragraph from Andrew Nacin around WordPress 4.2/4.3. - Documenting the role for future leads is one of her goals for the release. #### ⏱️ [08:20](https://www.youtube.com/watch?v=lR17090NeGA?t=500) Responsive styling demoed on a real site - Demos on her personal site deliberately, because she wants to see real content. Tests trunk daily, multiple times a day. - The cross-release build-up: 6.9 show/hide blocks → 7.0 show/hide by screen size → 7.1 responsive styling + custom navigation overlay. - Notes she ran the full site editing outreach program and that responsive control was "number one feedback." #### ⏱️ [10:00](https://www.youtube.com/watch?v=lR17090NeGA?t=600) What the toggle actually does - Off: previewing viewport modes. On: styling per viewport. - Her worked example — larger text on mobile, an image column hidden entirely because the photos "looked really distracting" small. - A mobile indicator marks where per-viewport values are set. Viewports themselves are customizable via theme.json. #### ⏱️ [11:30](https://www.youtube.com/watch?v=lR17090NeGA?t=690) "7.1 feels like a landing" - The convergence claim: multiple ways of controlling appearance across screen sizes now come together, rather than arriving as one feature. #### ⏱️ [12:30](https://www.youtube.com/watch?v=lR17090NeGA?t=750) Block states, and the Figma comparison - The underlying concept is block states — combining attributes to determine display, similar to a Figma capability. - Open UX question: styling tablet does not cascade to mobile below it. What *should* the behavior be? #### ⏱️ [13:20](https://www.youtube.com/watch?v=lR17090NeGA?t=800) The always-on debate - Someone argued responsive styling should always be on. She disagrees on air: sometimes you want to change something without considering whether it applies everywhere. #### ⏱️ [14:00](https://www.youtube.com/watch?v=lR17090NeGA?t=840) Pseudo-state styling unlocked it - No clear technical path existed until pseudo-state styling landed (hover styling for the button block, also in 7.1). - Her account of the sequence: the capability landed, the UX became clearer, and developers then generalized the pattern to responsive styling. "It's almost like you converge on a solution." - Future idea floated: animation. #### ⏱️ [15:20](https://www.youtube.com/watch?v=lR17090NeGA?t=920) API shape for humans and AI - With block states multiplying, the API had to be sustainable, scalable, and readable — explicitly "both to us humans and AI." - Open issues remain in the GitHub repo about the dropdown experience. #### ⏱️ [16:40](https://www.youtube.com/watch?v=lR17090NeGA?t=1000) Styles, not layout — the confusing part - The label says "responsive styles" deliberately. Deleting a block while in mobile deletes it outright. - Her own framing: "it basically takes style changes, but it doesn't take layout changes." Show/hide is the intended tool for the layout half. She expects this to need getting used to and further iteration. #### ⏱️ [17:40](https://www.youtube.com/watch?v=lR17090NeGA?t=1060) Command palette improvements - Recently-used entries, plus context-aware suggestions based on where you are in the admin. #### ⏱️ [18:20](https://www.youtube.com/watch?v=lR17090NeGA?t=1100) Site identity section - Built by McCarthy from user feedback; she notes it was "super easy to implement" and describes herself as technical but not overly so. - Targets the base experience of someone new setting up a site, without entering the editor — the job the theme customizer used to do for classic PHP themes. - She hits a live blank-screen bug on air, reported that morning, and cannot tell whether it is a Playground issue. "That's what betas are for." #### ⏱️ [20:00](https://www.youtube.com/watch?v=lR17090NeGA?t=1200) Playlist block - New core block with tabs and playlist display options and the customization expected of a core block. Plays audio. #### ⏱️ [20:40](https://www.youtube.com/watch?v=lR17090NeGA?t=1240) The omnibar - A persistent toolbar in the site editor, requested by Mullenweg because users landed in the site editor and couldn't find their way back. - The design principle stated directly: immersive is good, feeling trapped is not. Available everywhere. #### ⏱️ [21:20](https://www.youtube.com/watch?v=lR17090NeGA?t=1280) Untitled posts show an excerpt - Came from Dave Winer's feedback — he writes posts without titles and couldn't identify them in the list. - Design debate covered whether to show "no title" at all, and whether to italicize the excerpt. McCarthy notes she always sets titles herself, so *she* would want to see "no title." #### ⏱️ [22:40](https://www.youtube.com/watch?v=lR17090NeGA?t=1360) The classic block reversal - Planned: new installs without the classic block. Actual: deprecation continues, removal paused. - Driven by product stats showing it "was too used," surfaced when Mullenweg saw the deprecation notice while editing a friend's site. - The reframe: instead of how to remove it, ask why people still use it and what would bridge the gap. #### ⏱️ [24:00](https://www.youtube.com/watch?v=lR17090NeGA?t=1440) The forward/backward dance - Presented as a recurring per-release tension: pushing into the future while honoring backwards compatibility and respecting users. - Karkovack contrasts with vendors who "just remove it and they don't care," and notes the classic editor plugin still runs on millions of sites. #### ⏱️ [25:00](https://www.youtube.com/watch?v=lR17090NeGA?t=1500) "A human made that decision" - On being upgraded against your habits: she tells her partner that a human made the decision, and adds "we don't always get it right." - The argument that follows is the load-bearing one: how WordPress *feels* matters "especially in the age of AI" — familiarity and ease of use around your words, story, and business. #### ⏱️ [26:20](https://www.youtube.com/watch?v=lR17090NeGA?t=1580) Collaborative editing — the research - Phase 3 research a couple of years prior: roughly 25 organizations, large and small; summary public on Make/Core. - The finding that mattered: real-life usage is needed, not testing. What happens when you stop mid-article, walk away, go to lunch, come back? - WordPress VIP contributed to the feature and has people using it; more real users were wanted. - A new outreach program runs with Amy and Justin Tadlock. #### ⏱️ [28:00](https://www.youtube.com/watch?v=lR17090NeGA?t=1680) The primitives pivot - Mid-release the question became what could reasonably land. Proposal: skip HTTP polling as a works-everywhere default and ship primitives so hosts and plugins bring their own transport server. - Core provides tools; a host or plugin assembles them. "Rather than providing an out of the box default experience." - Result: "developer debates broke out" and very philosophical questions about how the experience should work. #### ⏱️ [29:30](https://www.youtube.com/watch?v=lR17090NeGA?t=1770) Google Docs is the expectation you're measured against - People carry a strong Google Docs connotation into "collaborative editing," creating high risk of shipping something that leaves a bad taste. - She reports feeling both the power and the tension, and having hit bugs herself. #### ⏱️ [30:30](https://www.youtube.com/watch?v=lR17090NeGA?t=1830) Why WP Admin is not a Google Doc - The philosophical core: writing in a Google Doc is "completely divorced from a website"; WP Admin has the publish button right there. - Large organizations face legal responsibility — "huge problems if they publish something and they can't track who wrote what," with litigation risk. A Google Doc insulates you; WP Admin does not. - Conclusion: collaborative editing needs surrounding safeguards and workflow, not just the editing feature. #### ⏱️ [31:40](https://www.youtube.com/watch?v=lR17090NeGA?t=1900) Who actually wants it now - Best-fit use case heard: small news organizations with high internal trust, eager to use it today — one outreach participant "chomping at the bit." - Counterweight from another participant: "we'd really have to lock down access." #### ⏱️ [32:30](https://www.youtube.com/watch?v=lR17090NeGA?t=1950) The decision to pull - 7.0 kept getting pushed while focus went to hyper-technical scale questions — storage, which database table, its structure. - Zooming out for 7.1, she "could see the writing on the walls: there is not enough time." - She told Mullenweg and Ventura she didn't think they should do it; both agreed. She notes that had they disagreed, it would have been a different conversation involving pushback. #### ⏱️ [34:00](https://www.youtube.com/watch?v=lR17090NeGA?t=2040) Client-side media processing - Headline: more format support, better performance, more reliability. Punted from 7.0, landing in 7.1. - Credits Adam Silverstein as lead with Andrew Serong and Pascal Birchler supporting. - Specifics: HEIC (iPhone) photo support; MP4↔GIF conversion both directions. - Framed as invisible foundational work — "does the upload work? Was the format allowed?" #### ⏱️ [35:30](https://www.youtube.com/watch?v=lR17090NeGA?t=2130) Attached images in galleries - Long-standing gap in the block editor: you could attach media to a post, but not use it. Now "use attached images" pulls them into a gallery automatically. - Also notes drag-and-drop into the inserter, which she says people often don't realize works. #### ⏱️ [36:30](https://www.youtube.com/watch?v=lR17090NeGA?t=2190) The new media cropper - Modernized cropper with flip support. She reports it eliminates her habit of editing photos before uploading them. #### ⏱️ [37:10](https://www.youtube.com/watch?v=lR17090NeGA?t=2230) Inline notes - Also led by Adam Silverstein. Notes move from block-level to inline — highlight a sentence, rich text, @mention people. - Notifications for @mentions targeted before Beta 2. #### ⏱️ [38:20](https://www.youtube.com/watch?v=lR17090NeGA?t=2300) Hidden gems - Admin color scheme now applies in the site editor, backed by a theme package update. She expects people won't think about it consciously but will feel the consistency. - Media library gains infinite scroll, toggled in profile settings. - "On this day" dashboard widget — design by Scott Riley (Coffee to Code). She connects it to her own five-year daily journal and to Strava, framing it as bringing people back to the dashboard "in a bit more of an emotional way." Another item Mullenweg raised in the 7.0 product review. #### ⏱️ [41:00](https://www.youtube.com/watch?v=lR17090NeGA?t=2460) Custom icon registration - The icon block landed in 7.0 without third-party registration. 7.1 adds an API so plugin and theme authors can register their own icons. - Karkovack notes that getting a Font Awesome icon into a headline was one of the first things he wanted when Gutenberg shipped. #### ⏱️ [42:30](https://www.youtube.com/watch?v=lR17090NeGA?t=2550) How to test, and why - Follow WordPress.org news; use Playground against latest trunk (which is how she finds and reports bugs). - The argument for testing now, at scale: a bug found in beta saves time multiplied across every user. "You're changing people's lives. You're not just changing their workflow." - She ties this back to why she loses sleep over the release. ## 📚 References - [The WP Minute](https://thewpminute.com/subscribe) — newsletter, membership, free Slack - [WordPress.org News](https://wordpress.org/news/) — beta announcements and testing instructions - [WordPress Playground](https://playground.wordpress.net/) — trunk testing without a local install - [Make/Core](https://make.wordpress.org/core/) — phase 3 collaborative-editing research summary - [WordPress 7.1 development cycle](https://make.wordpress.org/core/) — release squad and schedule - Contributors named: Anne McCarthy, Matt Mullenweg, Matías Ventura, Adam Silverstein, Andrew Serong, Pascal Birchler, Scott Riley, Amy, Justin Tadlock, Andrew Nacin (historical) ## 🗣️ Paraphrase - McCarthy is leading a WordPress release for the first time, having previously held test, coordination, and documentation roles on release squads. - The difference she describes is authority: her input now carries enough weight that she deliberately restrains how much she says in design discussions. - Her explicit goal for 7.1 is to lower the temperature after 7.0 — predictable, early, and smooth. - She found the release-lead role almost undocumented and intends to fix that for future leads. - Responsive styling is the headline capability, but she frames it as a convergence of work shipped across 6.9, 7.0, and 7.1 rather than a single feature. - It works through block states, and only became technically and experientially clear once pseudo-state hover styling landed. - Two caveats ship with it: whether it should be always-on is unresolved, and it captures style changes but not layout changes, which she expects to confuse people. - The API was designed for readability by both humans and AI, anticipating that block states will multiply. - Removing the classic block was paused because usage statistics showed it too heavily used, after Mullenweg encountered the deprecation notice on a friend's site. - She generalizes this into a recurring tension between advancing and preserving, and argues that how WordPress feels matters more in the age of AI. - Collaborative editing was pulled on her recommendation, with Mullenweg and Ventura agreeing. - Her earlier research across roughly 25 organizations established that real-world usage rather than synthetic testing is the missing input. - A mid-release pivot toward shipping primitives, so hosts and plugins supply their own transport, triggered unresolved developer debate. - Her strongest argument is contextual: WP Admin sits next to the publish button, and large organizations carry legal exposure if authorship cannot be tracked, so safeguards must ship alongside the feature. - Client-side media processing lands after being punted from 7.0, adding HEIC support and MP4-GIF conversion, framed as invisible foundational work. - Visible media improvements include using attached images in galleries, a modernized cropper, and inline notes with mentions. - Quality-of-life additions include the omnibar, command palette suggestions, a site identity section, excerpts for untitled posts, admin color schemes in the site editor, and media library infinite scroll. - An "on this day" widget designed by Scott Riley aims to bring people back to their dashboard for emotional rather than functional reasons. - Plugin and theme authors can finally register custom icons for the icon block, closing a gap from 7.0. - She urges beta testing on the grounds that a bug caught now saves time multiplied across every future user. ## 📰 Newsletter **The most interesting thing in WordPress 7.1 is what got pulled.** Anne McCarthy is release lead for WordPress 7.1 — her first time holding the final call — and her conversation with Eric Karkovack on [The WP Minute](https://thewpminute.com/) is worth an hour for the decisions, not the demo reel. Two of them stand out. **The classic block isn't going away.** The plan had new installs shipping without it; the plan changed when product stats showed it was simply too used, a conversation kicked off when Matt Mullenweg hit the deprecation notice while editing a friend's site. McCarthy's framing is the useful part: instead of asking how to remove it, ask why people still reach for it and what would actually bridge the gap. **And collaborative editing was pulled — on the release lead's own recommendation.** She told Mullenweg and Matías Ventura she didn't think it should ship. They agreed. Her reasoning is the sharpest thinking in the interview, and it isn't about engineering readiness. Everybody arrives at "collaborative editing" carrying a Google Docs expectation, and Google Docs is *insulated* — you're writing in a container, divorced from a website. WP Admin has the publish button right there. She talked to large organizations who face real legal exposure if they can't track who wrote what. So the feature isn't just the editing; it's the safeguards and workflow around it. Ship the first without the second and you've built something people can get sued over. What did land is genuinely good. **Responsive styling** — actual per-viewport styling, not just preview — arrives via block states, and McCarthy's framing is that 7.1 is a "landing" for work that started in 6.9 (show/hide blocks) and continued in 7.0 (show/hide by screen size). Two caveats she volunteers rather than hides: whether it should be always-on is still debated, and it takes *style* changes but not *layout* changes, so deleting a block in mobile view deletes it everywhere. Expect that one in support forums. **Client-side media** finally lands after being punted from 7.0 — HEIC support, MP4↔GIF conversion, plus a modernized cropper that McCarthy says broke her habit of editing photos before upload, "use attached images" for galleries, and inline notes with @mentions. Adam Silverstein has been carrying much of this. Small things that will matter more than they sound: the **omnibar** (Mullenweg asked for it because people got lost in the site editor — "great to be immersive, but not so much so that you feel trapped"), untitled posts showing an excerpt (Dave Winer's feedback, naturally), admin color schemes finally working in the site editor, and **custom icon registration** for the icon block, closing a gap from 7.0 that theme and plugin authors have wanted since Gutenberg shipped. And one for the "why does anyone do this job" file: McCarthy went looking for documentation on the release-lead role and found a single paragraph from Andrew Nacin, circa WordPress 4.2. She's writing the handbook as she goes. Go test it in [Playground](https://playground.wordpress.net/). Her pitch, and it's a good one: a bug you find now is time saved multiplied across every person who would have hit it. ## ✅ Action Items #### DevRel - Developer advocacy: build a demo showing responsive styling across the 6.9→7.0→7.1 arc; the convergence is the story and single-release framing undersells it. - Education: produce explicit guidance on the style-vs-layout distinction before support volume arrives — this is the predictable confusion of the release. - Developer experience: document the block-states API and the custom icon registration API with working examples. - Developer marketing: lead with "what got reconsidered" as a trust story; the classic-block reversal is better evidence of user respect than any feature. - Community management: recruit real organizations into the collaborative-editing outreach program with Amy and Justin Tadlock — real-world usage is the stated blocker. - Internal/external/cross-project: capture the release-lead role documentation McCarthy is writing so it survives past her tenure. #### OSPO - Policy & Governance: the classic-block reversal is a case study in evidence-based deprecation policy — codify "examine why it's still used" as a required step. - License Compliance: not applicable to this source — no licensing dimension is discussed. - Security Management: the collaborative-editing attribution requirement is a security and compliance concern, not just UX; track it as such. - Software Inventory: HEIC and new media format support changes the media-handling dependency surface; review it. - Developer Support: office hours for theme developers on theme.json viewport customization. - Community Engagement: fund or sponsor real-world collaborative-editing pilots, since that is the named gap. - Strategic Alignment: measure whether "bring the temperature down" produced a measurably calmer release than 7.0 — cycle time, reverted commits, blockers. #### Community - Maintainers: the primitives-vs-default-implementation debate is a reusable governance pattern; document how it gets resolved. - Contributors: first-time release-squad members are explicitly named as a contributor-journey moment — build onboarding around it. - Sponsors: sponsor the beta testing McCarthy is asking for; it is the highest-leverage volunteer contribution in the cycle. - Ecosystem: coordinate host readiness for the collaborative-editing transport-primitives approach before it lands. #### WordPress - Core: resolve the responsive-styling always-on debate and the tablet-does-not-cascade-to-mobile question before RC. - Core Performance: quantify the client-side media performance claim; McCarthy's "5 seconds to 2" framing is illustrative, not measured. - Core AI: the API-readability-for-AI consideration is a notable design input — document it as an explicit criterion. - **Core Program Team:** capture the release-lead handbook McCarthy is drafting; the current documentation is one paragraph from ~4.2. - Mobile: verify HEIC and MP4/GIF handling in the mobile apps. - Playground: McCarthy tests trunk in Playground daily and hit a bug she couldn't attribute — improve Playground-vs-core bug attribution signals. - Community: session on the responsive-styling workflow at upcoming meetups. - Training: Learn module for responsive styling and block states, including the style-vs-layout caveat. - Marketing: the "feel it" framing from the 7.0 product review is the release narrative; use the reversal stories as proof. - Support: prepare canned guidance for "I deleted a block in mobile view and it deleted everywhere." - Design: the untitled-post excerpt debate (italics? "no title"?) is unresolved — settle it with user testing. - Documentation: theme.json viewport customization and the icon registration API both need developer docs. - Photos: HEIC support has direct implications for the Photos directory contribution flow. - TV: caption and chapter this interview; the collaborative-editing segment deserves its own marker. - Polyglots: verify the new UI strings (responsive styling, omnibar, identity section) are translatable and unambiguous. - Accessibility: audit the omnibar, the new cropper, and inline notes for keyboard and screen-reader support before RC. - Meta: the product stats used to reverse the classic-block decision should be documented as a decision input. - CLI: consider WP-CLI support for inspecting per-viewport block state values. - Hosting: the transport-primitives approach for collaborative editing puts real work on hosts — start the conversation now. - Tide: block states expand the theme/plugin compatibility surface; consider scoring implications. - Openverse: not applicable to this source. - Themes: theme.json viewport customization and custom icon registration are both theme-author-facing; publish migration guidance. - Plugins: icon registration API is a new extension point — document and promote it. #### The WPOCC - Programs: fund contributor time for beta testing, which McCarthy identifies as the highest-leverage unpaid work in the cycle. - Projects: support the release-lead documentation effort; institutional knowledge currently rests on one paragraph from a decade ago. - Funding experiments: sponsor small news organizations to pilot collaborative editing, since that is the stated best-fit use case and the missing evidence. ### FAIR - Technical independence: not directly discussed, though the transport-primitives model for collaborative editing is the same "core provides tools, others assemble" philosophy. - Policies and covenants: the classic-block reversal demonstrates evidence-driven deprecation — a good pattern for any covenant about breaking changes. - Productized governance artifacts: the release-lead handbook is exactly the kind of governance artifact worth productizing across projects. ## 🧪 Hypotheses 1. Adding a mandatory "why is this still used" investigation before deprecation reduces reverted deprecations and post-release support volume. 2. Responsive styling's style-vs-layout distinction will generate a measurable spike in support requests within one release cycle of general availability. 3. Features whose UX debate is unresolved at beta ship with lower satisfaction scores than features whose UX settled before beta. 4. Real-world longitudinal usage surfaces different collaborative-editing defects than synthetic load testing, particularly around session resumption. 5. Documenting the release-lead role reduces onboarding time and decision latency for subsequent first-time leads. 6. Emotionally-framed dashboard features like "on this day" measurably increase dashboard return visits relative to purely functional widgets. ### 📊 Methodology - **H1:** Retrospective review of WordPress deprecations over the last ~15 releases, coding each for whether usage was investigated pre-decision, against outcome (completed vs. reverted) and support-forum volume. Confounder: high-usage features are both more investigated and more likely reverted. - **H2:** Interrupted time-series on support forum and Trac ticket volume matching the layout-change pattern, before and after 7.1 GA. Pre-register the search terms. - **H3:** Correlate a UX-settled-at-beta flag across recent features with post-release satisfaction survey data. Requires per-feature satisfaction instrumentation that does not currently exist. - **H4:** Two-arm study within the collaborative-editing outreach program — synthetic load testing vs. instrumented real-editorial usage — comparing defect classes surfaced. This is essentially the study McCarthy says is missing. - **H5:** Before/after comparison of time-to-first-decision and squad-reported clarity for release leads, pre- and post-handbook. Small n makes this qualitative. - **H6:** A/B the "on this day" widget by cohort, measuring dashboard return frequency and post-creation rate over 90 days. Ethical note: needs opt-in given it surfaces personal archives. ### ❓ Questions - Should responsive styling cascade downward from tablet to mobile, and what do users actually expect? - What are the specific usage statistics that reversed the classic-block decision, and can they be published? - If collaborative editing ships as primitives, what happens to sites on hosts that never implement a transport? - How will authorship attribution be guaranteed for the legal-exposure case large organizations raised? - Does "responsive styles" as a label adequately signal that layout changes are excluded? - What is the actual measured performance gain from client-side media processing? - Was the Playground bug McCarthy hit a Playground issue or a core one, and what does that ambiguity cost testers? - Does an emotional dashboard feature risk surfacing unwanted memories, and is there an opt-out? ### 🔮 Future Research - Study of how feature convergence across releases affects user comprehension — whether users perceive 6.9/7.0/7.1 responsive work as one capability or three disconnected ones. - Empirical work on deprecation in large installed bases, using the classic block as a case study with unusually good telemetry. - Research into collaborative editing in publication-adjacent contexts, where the distinction from document-editing tools is the central variable rather than an afterthought. - Investigation of whether API readability optimized for AI consumers diverges from readability optimized for humans, now that this is an explicit design criterion. - Longitudinal study of release-lead onboarding as documentation matures, which the handbook effort makes newly possible. ### 💡 Implications - **Practice.** Agencies and site builders get meaningfully better responsive control without a page builder, but need to internalize the style-vs-layout boundary before it bites them. - **Policy.** The classic-block reversal establishes a precedent worth codifying: usage evidence can override a deprecation roadmap. That is a meaningful constraint on future breaking changes. - **Security.** The authorship-attribution requirement reframes collaborative editing as a compliance feature. Any implementation shipping without audit trails inherits the legal exposure organizations described. - **Education.** Two teaching gaps open immediately: the style-vs-layout distinction for users, and block states plus theme.json viewports for developers. - **Funding.** Beta testing is the highest-leverage contribution in the cycle and is entirely unfunded. The release lead is explicitly asking for it. ### 🧠 Learning Styles Assessment - Reading level estimate: **Flesch-Kincaid Grade ≈ 8.2**, Flesch Reading Ease ≈ 64. Conversational and accessible in register, though the density of WordPress-specific terms (block states, theme.json, pseudo-state styling, omnibar, site editor, trunk) makes it effectively intermediate-to-expert for the ecosystem. #### 👀 Visual learners - Present: strongest dimension. This is a screen-shared demo — responsive styling toggled live, the cropper manipulated, the command palette opened. Seeing the mobile indicator appear is more instructive than any description. - Improve: much is deictic ("you'll see this little indication"), so the visual content doesn't survive audio-only consumption. Publish annotated screenshots and a diagram of the 6.9→7.0→7.1 convergence. #### 🔊 Aural learners - Present: natural two-person interview with genuine back-and-forth; the interviewer asks clarifying questions a listener would ask. - Improve: the demo segments are hard to follow without video. A separate audio-first summary covering decisions rather than demos would serve this group better. #### 🗣️ Verbal learners - Present: several vivid formulations — "great to be immersive, but not so much so that you feel trapped," "a human made that decision," "you're changing people's lives, you're not just changing their workflow." - Improve: terms like block states, pseudo-state styling, trunk, and primitives are used without definition. A glossary would widen the audience considerably. #### 🧩 Kinesthetic learners - Present: excellent — the entire thing is a call to action to spin up Playground and test trunk, with a direct path to doing it. - Improve: publish a Playground blueprint preloaded with 7.1 beta and a short guided testing script, so "go test" becomes a concrete task rather than an invitation. #### 🧠 Logical learners - Present: the cross-release progression is laid out clearly, and the collaborative-editing decision is explained with reasoning and named tradeoffs rather than asserted. - Improve: a decision matrix for what shipped vs. what was pulled, with the criteria applied, would make the reasoning reusable by other release squads. #### 🧑‍🤝‍🧑 Social learners - Present: strong contributor-credit throughout — Silverstein, Serong, Birchler, Riley, the Tadlocks, Nacin. The release squad's first-timers are named as significant. - Improve: link the outreach programs and squad channels in show notes so listeners can act on the repeated invitations to participate. #### 🧘‍♀️ Solitary learners - Present: works well for independent listening; McCarthy narrates her own testing practice, which is a solitary discipline. - Improve: add self-check prompts — "can you state what responsive styling will and won't carry across viewports?" #### 🌿 Naturalistic learners - Present: thin, but the client-side media efficiency argument (5 seconds to 2, multiplied across every image and user) is implicitly a resource-consumption story. - Improve: make the energy/lifecycle framing explicit — client-side processing shifts compute from server to client, which has real aggregate implications worth naming. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: auto-captions exist. - Improve: caption accuracy is poor on names and terms — "An McCarthy" (Anne), "Andrew Nason" (Nacin), "omniar" (omnibar), "Raone" (Pascal Birchler), "Straa" (Strava), "PressVip" (WordPress VIP), "primitives primitives." Names of contributors being mangled is a credit problem as well as an accessibility one. **WCAG 2.2 AA 1.2.2**. #### Keyboard navigation - Present: standard player controls. - Improve: no chapter markers across a ~45-minute interview with at least eight distinct segments. **2.4.5 (Multiple Ways)**. #### Contrast and readability - Present: the screen-shared WordPress admin at default settings generally meets contrast requirements. - Improve: admin UI shared at native resolution is small on a video stream; zoom during demos. **1.4.3**, **1.4.4**. #### Text resizing and reflow - Present: platform-level only; shared screen content cannot be resized by the viewer. - Improve: publish the demonstrated settings as text/screenshots so viewers can zoom independently. **1.4.4 (Resize Text)**, **1.4.10 (Reflow)**. #### Media and captions - Present: captions and a full-length recording; the interviewer sometimes verbalizes what is on screen. - Improve: this is the significant gap. Substantial content is purely visual and referenced deictically — "you'll notice that I actually changed the font size," "you'll see this little indication." A blind listener cannot follow the demos. Audio description or disciplined verbal narration is needed. **1.2.3 / 1.2.5 (Audio Description)**. - Note in the product itself: the interview does not mention accessibility testing for the omnibar, cropper, or inline notes — all new interactive surfaces. #### Forms and interactions - Not applicable to the video as media. Worth flagging for the *product*: the new site identity section, cropper, and inline notes are form-bearing interfaces whose label and error handling are unexamined here. **3.3.2 (Labels or Instructions)**. #### Standards reference - Media gaps: **1.2.2** (caption accuracy on names/terms), **1.2.3/1.2.5** (unnarrated visual demos), **2.4.5** (no chapters). Product-side, **2.1.1** and **4.1.2** for the new interactive components remain unverified from this source. ### 🌍 DEIB Assessment #### Cultural breadth - Present: the release squad's wide time-zone spread is named as a real constraint requiring two separate calls — a small but concrete accommodation. - Improve: examples and references are US-centric (Strava, Font Awesome, the soccer/World Cup metaphor with an American hedge). Localization and RTL implications of responsive styling and the omnibar go unmentioned, which is a substantive gap for a global project. #### Inclusive language - Present: consistently gender-neutral; contributors credited by name without diminishment. McCarthy refers to her partner without gendering assumptions being imposed by the interviewer. - Improve: heavy jargon assumed as shared knowledge — trunk, primitives, block states, theme.json — raises the barrier for the newcomers the release explicitly wants testing. The show notes should carry a glossary. #### Neurodiversity support - Present: McCarthy's disclosure that she is "pretty verbose" and consciously self-regulates in discussions is a small, unremarked instance of someone naming their own working style. Her five-year-journal habit and daily testing routine model structure and repetition openly. - Improve: a 45-minute unstructured interview with live demos, screen-sharing hiccups, and topic-switching is hard to navigate. Chapters and a written feature summary would materially help. #### Representation - Present: notable. A woman is leading a major WordPress release and is the technical authority throughout, describing herself as "technical but not like overly technical" while having personally implemented a shipped feature. That combination — visible authority plus honest self-assessment — is good modeling. Contributors named span multiple roles and backgrounds. - Improve: the decision-making figures named at the top (Mullenweg, Ventura) are men, and the framing "I can think of a lot of people who would probably be better suited for this" is self-deprecation worth noticing in context, though she immediately follows it with confidence about her approach. #### Psychological safety - Present: the strongest dimension here. She hits a live bug on air and treats it as normal — "that's what betas are for." She says "we don't always get it right" about product decisions and explains to non-technical people that "a human made that decision," which converts user frustration into something addressable rather than personal failure. Crediting first-time squad members and describing dissent to Mullenweg and Ventura as normal both model a safe environment. - Improve: only that the interview is one-sided. Contributors on the pulled features may experience the decisions differently, and their perspective is absent. ### ✅ Logical Validity #### Strong reasoning - **Evidence overriding plan, [22:40].** The classic-block reversal is well-reasoned: a roadmap commitment was checked against usage telemetry, the telemetry contradicted it, and the plan changed. The reframe — ask why it's used rather than how to remove it — converts a removal decision into a diagnosis. Strengthen by publishing the statistics. - **Distinguishing contexts rather than features, [30:30].** The argument that WP Admin is not Google Docs is the strongest reasoning in the interview. It identifies a *structural* difference — proximity to publication and consequent legal exposure — rather than a capability gap, and derives a correct conclusion: safeguards must ship with the feature. This is a category distinction, not a preference. - **Argument from scale, [42:30].** "A bug you find now saves 10 seconds for everyone who would have hit it" is a valid multiplication argument that correctly identifies why pre-release testing has outsized value. It also honestly explains her own stated anxiety rather than performing it. - **Convergent discovery reported accurately, [14:00].** Her account of pseudo-state styling landing first and responsive styling becoming clear afterward describes an emergent rather than planned path. Reporting that a design was discovered rather than intended is credibility-increasing and rarely done. - **Disagreeing on record, [13:20].** Asked about always-on responsive styling, she states her disagreement with a named position and gives the reason. Public disagreement with an unnamed advocate, with reasoning attached, is better epistemic practice than deferring. #### Fallacies - **Appeal to unpublished authority — [22:40].** "There are certain stats that we have access to" justifies reversing the classic-block deprecation, but the statistics are never shown or characterized. **Weakness:** the audience cannot evaluate the decision, and "stats we have access to" implies privileged data that shapes public product direction without public scrutiny. **Fix:** publish the usage figures, even rounded, alongside the decision. - **Anecdote driving a roadmap decision — [22:40].** The trigger was Mullenweg noticing a deprecation notice while editing a friend's site. **Weakness:** the sequence presented has an individual's incidental observation initiating reconsideration of a planned change. Even where the subsequent analysis was sound, this reveals a decision process sensitive to who noticed what, which is not a scalable input. **Fix:** describe the systematic check that *should* have caught it, and whether one now exists. - **Equivocation on "responsive styles" — [16:40].** The label is defended as intentional because the feature takes style but not layout changes. **Weakness:** users do not partition "hide this block on mobile" as layout rather than style; the distinction is an implementation boundary presented as a naming solution. McCarthy half-concedes this by predicting confusion. **Fix:** the UI should prevent or warn on destructive layout operations while in a viewport context, rather than relying on the label. - **Appeal to consequences — [29:30].** Collaborative editing is partly justified as unshippable because it risks "leaving a bad taste in the mouth" against Google Docs expectations. **Weakness:** perceived comparison is a reason to manage expectations, not evidence the feature isn't ready. It sits alongside genuinely strong reasons (attribution, legal exposure, time) and is the weakest of them. **Fix:** rank the reasons; the legal-attribution argument alone is sufficient. - **False dilemma (mild) — [28:00].** The primitives pivot is framed as HTTP-polling default *or* host-supplied transport. **Weakness:** a default implementation with a pluggable override is the common third option and is not discussed. **Fix:** state why the hybrid was rejected, if it was. - **Hasty generalization — [24:00].** Karkovack's "if Microsoft wants to remove something, they just remove it and they don't care," accepted without qualification. **Weakness:** a sweeping characterization of another organization's deprecation practice offered without evidence, functioning to flatter the in-group. **Fix:** compare specific deprecation policies, or drop the comparison. - **Unfalsifiable framing — [25:00].** "How WordPress feels really matters, especially in the age of AI." **Weakness:** intuitively appealing, but no mechanism connects AI's rise to familiarity's increased value, and no measure is proposed. It functions as a justification for conservatism that could support any decision. **Fix:** specify the claim — e.g. that switching costs fall when AI lowers migration effort, so retention depends more on habit. #### Tone of voice - Enthusiastic, self-disclosing, and notably unguarded for someone representing a release. McCarthy volunteers difficulties — sleepless nights, a live bug, an unresolved UX debate, a feature she recommended pulling — rather than managing the narrative. The register is practitioner-to-practitioner, and she consistently redirects credit to named contributors. Where the tone shifts is the collaborative-editing segment, which becomes noticeably more careful and more philosophical; she signals the shift herself ("I'm going to get philosophical for a second"). Karkovack is warm and low-friction, which produces candor but means few claims are pressed. The overall effect is high trust and low scrutiny — the listener learns a great deal about what the release lead thinks and very little that challenges it. ### 🛡️ DARVO Analysis - **Deny:** Not present. The interview is unusually forthcoming about problems — a live bug is demonstrated rather than edited out, an unresolved UX debate is described as unresolved, and two planned features are acknowledged as not shipping. Where denial would be easy, disclosure occurs instead. - **Attack:** Not present against any individual. The one attack-shaped utterance is Karkovack's dismissal of Microsoft's deprecation practice, which targets a corporation's process rather than a person and functions as in-group flattery; it is logged under Logical Validity as a hasty generalization rather than as DARVO. - **Reverse victim/offender:** Not present. McCarthy consistently positions decision-makers, including herself, as responsible — "a human made that decision," "we don't always get it right." That is the inverse of the DARVO move: she assigns agency to the party with power rather than recasting them as constrained or wronged. - **Emotional cues and rhetoric:** Predominantly accountability and enthusiasm. The recurring rhetorical move is taking responsibility on behalf of decision-makers to *relieve* users of self-blame for confusion, which is the opposite of shifting blame onto them. - **Assessment:** No DARVO structure present. Recorded per template requirements rather than omitted. ## 🎯 Conclusion - **Bottom line.** WordPress 7.1's substantive story is restraint. Responsive styling is a real capability that completes a three-release arc, and client-side media finally lands, but the decisions that will matter longest are the two reversals: the classic block stays because usage evidence beat the roadmap, and collaborative editing was pulled because the release lead judged that shipping the editing without the attribution and workflow safeguards would harm the organizations most likely to use it. Both were argued, not asserted. The weakest link in each is transparency — the deciding statistics were not published, and the reconsideration was triggered by an individual noticing something rather than by a systematic check. - **Next steps for readers.** - Test in Playground against trunk now. McCarthy's scale argument is correct, and beta is when a report is cheapest. - If you build sites: learn the style-vs-layout boundary in responsive styling before a client deletes a block "just on mobile." - If you build themes: theme.json viewport customization and custom icon registration are both new extension points worth adopting early. - If you run an editorial team: the collaborative-editing outreach program wants real organizations, and the attribution requirement is worth raising while the design is open. - If you write release process: the release-lead role had one paragraph of documentation. Whatever McCarthy publishes is worth reading regardless of project. ## 🔄 Refactor Appendix — Why WordPress 7.1 Will Improve Your Workflow > Density: 2–5 Literature atoms (H3), 0–3 Permanent candidates (H4). > Defaults: 3 Literature, 1 Permanent. Resonance filter: if you can't > articulate in one line why a claim matters, drop it. > > Konik claim-header rules: present tense, declarative, ≤10 words when > possible, searchable, unique, mirrors annotation focus if present. > > Atomicity: one declarative sentence per atom. "and"/"also" → split. > > Tag pool: #bmf · #addendum · #xref · #articleseed · #storystem · #share · #aphorisms ### 📚 Literature Atoms (H3) #### [H1] Publishing proximity makes collaborative editing a compliance problem > [!quote] ID:rw_wpm71_h1 > There's huge problems if they publish something and they can't track who wrote what **Context & use**: - [30:30] — the philosophical core of why collaborative editing was pulled - The category distinction: a Google Doc insulates you from publication, WP Admin does not. Attribution is therefore a legal requirement, not a nicety, which means safeguards must ship with the feature rather than after it. **Tags**: #xref #share #articleseed **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> #### [H2] Usage evidence can override a deprecation roadmap > [!quote] ID:rw_wpm71_h2 > it was too used **Context & use**: - [22:40] — why the classic block's removal was paused - The reframe worth keeping: ask why something is still used rather than how to remove it. Precedent-setting for breaking changes in large installed bases; weakened by the statistics never being published. **Tags**: #xref #articleseed **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> #### [H3] Features converge across releases rather than landing whole > [!quote] ID:rw_wpm71_h3 > people sometimes fixate on just one release when in truth a lot of the times we're shipping things in different releases **Context & use**: - [08:20] and [11:30] — the 6.9 → 7.0 → 7.1 responsive arc - Also describes the discovery path: pseudo-state styling landed first, which clarified the UX and let developers generalize. Design was found, not planned. **Tags**: #xref **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> #### [H4] Immersive interfaces must not feel like traps > [!quote] ID:rw_wpm71_h4 > it's great to be immersive, but not not so much so that you feel trapped **Context & use**: - [20:40] — the design rationale for the omnibar - Generalizable UX principle: focus modes need a visible exit. The failure it fixes is users landing in the site editor and not knowing how to leave. **Tags**: #xref #aphorisms **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> #### [H5] A beta bug found is time saved times every user > [!quote] ID:rw_wpm71_h5 > You're changing people's lives. You're not just changing their workflow. **Context & use**: - [42:30] — the pitch for beta testing - The multiplication argument for why pre-release testing has outsized leverage, and the honest explanation for the release lead's stated sleeplessness. **Tags**: #xref #share #aphorisms **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates (H4) #### [P1] Shipping a capability without its safeguards transfers risk to users **Claim** (one sentence, Courtney's voice): A feature that changes who can act on a system must ship with the attribution and workflow controls that make the change auditable, or the risk it creates lands on the people adopting it. **Evidence pointer**: [[#H1]] **Scope & conditions**: Holds where the action has external consequences the organization is accountable for — publication, payment, disclosure. Breaks for low-stakes or fully reversible contexts, such as small teams with high internal trust, which is exactly the use case the source identifies as ready today. Also weakens where the surrounding platform already supplies the audit trail independently. **Links**: - [[Gate Contributions on Demonstrated Comprehension Not on Tooling]] — because extends: both put the burden of verifiability at the point where consequence is created - [[The Maker Should Not Grade Its Own Homework]] — because applies-in: attribution is what makes independent review of published work possible at all - [[Maintainer Attention Is the Scarce Resource in Open Source]] — because contrasts on where the cost lands <!-- atomicity: 1 idea ✓ --> #### [P2] Deprecation should begin as a diagnosis, not a removal plan **Claim** (one sentence, Courtney's voice): Persistent use of a feature slated for removal is evidence of an unmet need, so the first step is finding out what that need is. **Evidence pointer**: [[#H2]] **Scope & conditions**: Holds where usage telemetry exists and the installed base is large enough that removal imposes real migration cost. Breaks for security-forced removals, where the need is real but must be met another way regardless. Also breaks where usage is inertial rather than needful — the diagnosis can return "no unmet need," which is a valid answer the frame must allow. **Links**: - [[Portability Is Proven by a Second Implementer Not by Design Intent]] — because contrasts on how a design claim gets tested against reality - [[When Answers Are Cheap Understanding Becomes the Scarce Good]] — because applies-in: understanding *why* is the scarce input, not the removal decision itself <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] The classic-block usage statistics are referenced but never published — ask whether they can be. Decision transparency gap. #fleeting #inbox - [F2] Style-vs-layout in responsive styling will generate support volume; draft the explainer before GA. #articleseed #fleeting #inbox - [F3] Release-lead role had ONE paragraph of docs (Nacin, ~WP 4.2). Watch for McCarthy's handbook — institutional-knowledge case study. #xref #fleeting #inbox - [F4] "API readable by humans AND AI" as an explicit core design criterion — new, worth tracking whether it diverges. #articleseed #fleeting #inbox - [F5] Collaborative editing as primitives-not-defaults: same "core provides tools, others assemble" shape as FAIR's extension model. #xref #fleeting #inbox - [F6] Accessibility of omnibar / new cropper / inline notes is unmentioned — check before RC. #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Test WordPress 7.1 beta in Playground and file at least one issue — release contribution #things - [ ] Draft the responsive-styling style-vs-layout explainer for Training before 7.1 GA — docs gap #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/Why WordPress 7.1 Will Improve Your Workflow.md|Why WordPress 7.1 Will Improve Your Workflow by The WP Minute]] ## Highlights - [00:00:48] >> Yeah, that was something in WordPress 7.0 and the product review call that we did with Matt that he talked about like whenever people update to a new version of WordPress, he wants them to feel it. And so that was something with this release that I'm really excited about. There are many different things whether it's the omniar or a new on this day widget or a new functionality, new blocks um that you feel as you're using different parts of the experience that make it just yeah more powerful, easier to use. And it's some of it's subtle, some of it's more in your face. Um but I'm excited to see how the community reacts to it and how it helps improve the user experience. >> I've been having a lot of fun with it so far, but I wanted to dig in first because this is your first time as release lead, right? >> Yes. Yeah. >> So, so I I read you have a blog post, we'll put it in the show notes, about some sleepless nights and, you know, waking up in the middle of the night and ([View Highlight](https://read.readwise.io/read/01kyj66gbhc5pz4t17x3ppsfw4)) - Note: [H1] The release's guiding design philosophy (attributed to Matt Mullenweg): updates should be *palpably felt*, not just documented. Frames the whole episode's editorial lens — every 7.1 feature gets implicitly judged against this "do you feel it" bar. Useful as the top-line intent quote for any WP 7.1 summary. Contrast directly with the WPBeginner written coverage in the same inbox, which frames 7.1 as "no blockbuster, many annoyances fixed" — the podcast's "feel it" framing and the article's "quality-of-life" framing are describing the same release with opposite emotional valence, which is itself worth noting about how release comms get shaped. - Tags: wordpress-releases, atom/literature/h1 - [00:17:29] better. Um, and so in this case, Matt, I think, was editing an old um, friend's site and noticed that there was a deprecation notice that we had in place for this and brought it up. Um, which was great. Like I think flipping the question on its head and that made the developers who are working on it think a bit more deeply and kind of say, okay, let's pause this. Let's not let's not step forward. Um, and so every release that that tends to happen, there tends to be something where it's how do you push into the future while also, you know, backwards compatibility, honoring the past, respecting your users. Like there is like an interesting dance there. Um, and this was a good example of that where uh the thought process was to take a step back and examine why it's still used um and provide other pathways other than other than just deprecation. What else can we do? Let's zoom out and ([View Highlight](https://read.readwise.io/read/01kyj673hdad5sh5gtm4xj2apb)) - Note: [H2] FALLACY (appeal to authority) — flagged, but with nuance. The pivot where a stats-driven classic-block removal plan reversed into deprecate-not-remove, triggered by Matt noticing a deprecation notice while editing a friend's site. Exposes a recurring decision pattern in this interview: a single-stakeholder anecdote treated as validating signal for a roadmap change. The *outcome* (respect backwards compatibility, don't yank features users still rely on) is sound; the *mechanism* (it took the founder personally hitting it) is the governance smell worth naming — how many equally-valid concerns don't get a roadmap reversal because they aren't raised by the one person who can stop the release? Directly relevant to the WordPress governance thread. - Tags: wordpress-releases, atom/literature/h2, fallacy/appeal-to-authority