Community + Code: Episode 28 - Carrie Dils  🔗 **Source:** [Community + Code: Episode 28 - Carrie Dils](https://www.youtube.com/watch?v=czdljy6qrig) > [!note]+ Document Notes > tags: [wordpress, fair-project, supply-chain-security, teaching-as-learning, open-source-governance, composer, developer-tools] > author: Community + Code (podcast) > source: https://www.youtube.com/watch?v=czdljy6qrig > reference: https://www.youtube.com/watch?v=czdljy6qrig > date created: 2026-06-23 00:00 > > > [!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. > > > [!note] Re-upload > > The channel re-uploaded this episode on 2026-09-22 as https://www.youtube.com/watch?v=0NgRnXjGZH8 (92–95% identical transcript). This original doc stays canonical. > > > # 🏷️ Title: Community + Code: Episode 28 - Carrie Dils > <!-- 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 - [FAIR — Federated and Independent Repositories](https://fair.pm/) - [Linux Foundation](https://www.linuxfoundation.org/) - [TYPO3 CMS](https://typo3.org/) - [Carrie Dils](https://kydils.com/) ## 📝 Summary - Chris Reynolds interviews Carrie Dils, a longtime WordPress developer, freelancer, consultant, and educator, on episode 28 of Community + Code. - Dils traces a "windy road" career: building HTML pages in the mid-90s, a decade-long detour at Starbucks Corporation, then a 2012 return to tech via WordPress (around version 3.x), and a decade-plus teaching on Lynda.com / LinkedIn Learning. - A major thread is the "teaching as learning" philosophy — explaining a concept to someone else forces deeper understanding and cements knowledge better than passive consumption. - The conversation's core is FAIR (Federated and Independent Repositories), the Linux Foundation-backed project Dils co-chairs, built to solve the supply chain security problem for WordPress plugins and themes, and intentionally made CMS-agnostic. - Why it matters: FAIR addresses a real, non-hypothetical risk — that WordPress.org could be turned off or compromised — by adding trust signals, provenance verification, and vulnerability checks to package management. - Stakeholders: WordPress developers and site owners, the FAIR TSC and Linux Foundation, TYPO3 leadership, Cloudflare (with its new "Mdash" reimagining of WordPress), and the broader open source ecosystem. - Risks and tradeoffs: FAIR hasn't yet found widespread WordPress adoption; a key Yoast-aligned contributor (Karim/Mirichi context) stepped back after funding fell through; the composer-vs-low-barrier debate exposes a core tension between developer power and non-technical accessibility. - Bottom line: FAIR is alive and cross-pollinating (a working TYPO3 implementation came out of the March hackathon) even as its WordPress traction lags expectations. ## 📖 Main Content - Dils frames her career as nonlinear: an HTML elective in college (mid-90s) became her only marketable skill, leading to freelance web work, then burnout, then Starbucks ("learned on their dime"), then a return to WordPress around 2012 when she realized she could earn more building sites than "slinging coffee." - She and Reynolds reminisce about pre-GitHub/SourceForge tooling — Hot Scripts (a directory of free PHP/Perl/ASP scripts), rolling your own CMS, "web logs" edited over FTP, and abandoned-maintainer projects like sBlog that pushed users toward WordPress. - They note a recurring "not every site needs a CMS" argument (Yoast moving his blog to Astro) is decades old but now carries an "AI spin" — the claim that AI can build a site so you don't need a CMS. Dils' nuance: you *never* strictly needed a CMS; it just helps with some things, and not every job needs the same tool. - On education: Dils started teaching after Morten Rand-Hendriksen (her own Lynda.com instructor) suggested it. Reynolds parallels his own Pluralsight entry. Both describe how early online-course production was "bootstrappy" — instructors handled subject expertise, scripting, recording (Camtasia), editing, and audio engineering themselves. - The teaching-as-learning core: Dils built courses by reading source material (e.g., Brad Williams' books) chapter-by-chapter, and Reynolds learned internationalization by reading then teaching it. Explaining forces the brain to work differently and "to be able to teach it, you have to understand it thoroughly." - FAIR origin: after the September 2024 WordPress governance/ownership controversy ("happenings in the community"), Dils — previously content in "happy la-la land" — saw the governance and ownership concerns as a wakeup call. FAIR formed from several groups merging, with Linux Foundation guidance on best practices and a Technical Steering Committee (TSC) structure: contributors → organizers/voting members → three co-chairs (chosen over a single chair for diversity of perspective). - FAIR's purpose: solve the supply chain problem — "what if somebody turns WordPress.org off?" — which is both technical and a business problem, and which already literally happened for a specific audience. FAIR adds trust signals: verifying a package is who and where it claims to be, and that it has no known active security vulnerabilities. - Contested/uncertain claims: Dils is candid that widespread WordPress adoption "hasn't happened" and may not materialize. She frames FAIR's agnostic design as a hedge — usable by any community needing package management. - Cloudflare's "Mdash" (a quasi-fork of WordPress on Astro, running in the cloud via service workers) is raised as convergent evidence: it isolates plugins from the codebase precisely because the WordPress plugin ecosystem's outdated-plugin/CVE problem is "impaired" (Reynolds avoids "broken"). Supply chain security is a known problem outside WordPress too (npm attacks). - Composer thread: Dils has been "beating that drum" for composer support in FAIR for nearly a year. Drupal bakes composer into the platform; WordPress never has, so the community was never forced to think about it. TYPO3 (which uses composer, with both composer and non-composer versions) being an open consumer of FAIR forces the question — and the answer benefits everyone. - Persona tension: WordPress' low barrier attracted a "largely non-technical user base" who will never open a terminal; Drupal has the inverse problem (barrier too high) and is now courting non-technical "site builders." Dils' principle (echoed by Reynolds): don't force a site owner to become a developer, though a developer can be a site owner. ### 🗒️ Notes #### ⏱️ [00:00:00](https://www.youtube.com/watch?v=czdljy6qrig?t=0) Host intro and framing - Chris Reynolds hosts; guest Carrie Dils built sites in the mid-90s, left for ~a decade at Starbucks, returned to WordPress ~2012. - Episode previews: building a LinkedIn Learning course, teaching-as-learning, old-web tooling (Hot Scripts), and FAIR (Federated and Independent Repositories), the Linux Foundation-backed project she co-chairs. - FAIR targets the supply chain security problem for WordPress plugins/themes and the broader open source ecosystem; the TYPO3 March hackathon is flagged as an exciting development. #### ⏱️ [00:03:00](https://www.youtube.com/watch?v=czdljy6qrig?t=180) Origin story — the windy road - College HTML elective (mid-90s) was her only real skill on graduating → freelance web dev → burnout → Starbucks Corporation for ~a decade ("learned on their dime"). - A coworker told her about WordPress; she was "amazed... all this stuff just exists out of the box" vs. rolling your own CMS. Switched back to tech ~2012 at roughly WordPress 3.x. #### ⏱️ [00:04:30](https://www.youtube.com/watch?v=czdljy6qrig?t=270) Old internet — Hot Scripts and rolling your own - Reynolds' first WordPress was ~2.5; recalls Hot Scripts (chili-pepper logo), free PHP/Perl/ASP scripts you'd download and drop on your site. - "Web logs" edited as raw HTML over FTP; sBlog as a roll-your-own CMS whose maintainer disappeared (a recurring open-source pattern) pushing him to WordPress. #### ⏱️ [00:08:00](https://www.youtube.com/watch?v=czdljy6qrig?t=480) "Not every site needs a CMS" — now with an AI spin - 20-year-old conversation (Yoast → Astro) resurfacing with the AI claim "you don't need a CMS, AI can build it." - Dils: you never *needed* a CMS; it helps with some things. Reynolds: "oo" to AI building it, not to not needing a CMS — not everything needs the same tool. Maybe a return to a simpler web. #### ⏱️ [00:10:00](https://www.youtube.com/watch?v=czdljy6qrig?t=600) Into teaching — Morten and Lynda.com - Learned WordPress on Lynda.com from Morten Rand-Hendriksen, who suggested she teach. First course → "fell in love with the process." - Motivation: empowering others to understand the *why*, "not just copy pasting." A decade-plus now with LinkedIn Learning. #### ⏱️ [00:13:00](https://www.youtube.com/watch?v=czdljy6qrig?t=780) Course production — bootstrappy reality - Reynolds got into Pluralsight after a WordCamp theme-dev talk; "it'll be the same as your talk" — narrator: it was not. A 4–8 hour course differs hugely from a 30-minute talk. - Early Pluralsight reimbursed Camtasia and a mic; instructor did all editing/prep/audio engineering. LinkedIn Learning now more structured: pitch → audience → learning objective → table of contents → prerequisites/learner paths, with full post-production support. #### ⏱️ [00:18:00](https://www.youtube.com/watch?v=czdljy6qrig?t=1080) Personal brand and named-author gravity - Pluralsight author summits gave rare peer feedback. Well-known Microsoft-space authors' names "carried weight" and got more viewers — a "natural gravity." - Newcomers had to build a personal brand themselves; little official marketing push. "Everything is hard." #### ⏱️ [00:22:00](https://www.youtube.com/watch?v=czdljy6qrig?t=1320) Differentiating course topics - LinkedIn Learning is intentional about not having competing topics. Dils started with Genesis framework courses, then expanded as Morten moved off WordPress content, leaving a hole; later branched into front-end. - Reynolds entered Pluralsight WordPress space with "zero" competition, then narrowed via theme dev → bought Brad Williams' books and turned chapters into classes. #### ⏱️ [00:27:00](https://www.youtube.com/watch?v=czdljy6qrig?t=1620) Teaching as learning - "Hear the thing, read the thing, do the thing" then teach it locks it in. Reynolds' i18n course burned the knowledge into his brain. - Dils: explaining "forces your brain to work in a different way"; her blog started as tutorials — "I learned how to do something, let me tell you how." To teach it you must understand it thoroughly. #### ⏱️ [00:31:00](https://www.youtube.com/watch?v=czdljy6qrig?t=1860) Tunnel vision and broadening out - Dils stayed "primarily and largely" in WordPress; wishes she'd dipped toes into other CMSs earlier. FAIR opened her eyes to how other projects build, govern, and operate. #### ⏱️ [00:33:00](https://www.youtube.com/watch?v=czdljy6qrig?t=1980) Getting involved in FAIR - After September [2024] community "happenings," she was appalled; realized governance/ownership concerns weren't new — she'd been ignoring them in "happy la-la land." - Conversations with like-minded folks → several groups merged into FAIR. Core question: "what if somebody turns WordPress.org off? How are we still powering our sites and receiving updates?" Technical *and* business problem — and it literally happened for a specific audience. #### ⏱️ [00:36:00](https://www.youtube.com/watch?v=czdljy6qrig?t=2160) FAIR governance structure - New territory for Dils; Linux Foundation provided guidance and still supports FAIR. Formed a Technical Steering Committee (TSC). - Levels: contributor (PR/meeting participation) → organizers (core/voting members) → chair. FAIR chose three co-chairs for diversity of personality and perspective. Dils elected ~a year ago; a new election round is due around airing. #### ⏱️ [00:39:00](https://www.youtube.com/watch?v=czdljy6qrig?t=2340) What's worth volunteering for — trust signals - Much of her hope was widespread WordPress adoption, which "at the moment, hasn't happened." Glad FAIR is agnostic / usable by other CMS communities. - The pain scenario: inherit a site with 50 plugins, 34 out of date; short of "yoloing the update button," you're "a little bit blind." FAIR verifies a package is who/where it claims to be and free of known active vulnerabilities — confidence that "currently just doesn't exist" for WordPress plugins. #### ⏱️ [00:43:00](https://www.youtube.com/watch?v=czdljy6qrig?t=2580) Cloudflare's Mdash convergence - Cloudflare announced "Mdash," a quasi-fork of WordPress on Astro, cloud-hosted via service workers, isolating plugins from the codebase. - Rationale: the plugin ecosystem is "impaired" — outdated plugins, CVEs, file-system writes, potential infections. Patchstack/Wordfence/auto-updates help but don't solve it board-wide; a bad actor inside WordPress.org is "not impossible." Supply chain attacks already hit npm constantly. #### ⏱️ [00:47:00](https://www.youtube.com/watch?v=czdljy6qrig?t=2820) Cloudflare as a newcomer to the ecosystem - Cloudflare isn't an established community player; Reynolds first met Cloudflare reps (a sales guy + a developer) at BADCamp (Bay Area Drupal) last October. - Context: AI bot crawlers exploded since ~March, sending exponential traffic to sites (seen at Pantheon); Cloudflare shipped free bot protection that everyone signed up for. "What else you got cooking?" — now we know. #### ⏱️ [00:51:00](https://www.youtube.com/watch?v=czdljy6qrig?t=3060) TYPO3 hackathon and FAIR's future - Context: Karim/Mirichi and Yoast-aligned folks took "a few steps back" from FAIR after failing to secure funding/buy-in. - TYPO3 + FAIR ran a late-March hackathon producing a working FAIR implementation on TYPO3 to serve extensions (akin to plugins), now being added into TYPO3 core for baked-in support. A "very real collaboration." Brent and others on the TSC better placed on future plans. #### ⏱️ [00:55:00](https://www.youtube.com/watch?v=czdljy6qrig?t=3300) Composer, generic design, and competition - Competition is good; a generic platform built in a WordPress context but usable by anyone forces new thinking. Composer support has been Dils' year-long drumbeat. - Drupal bakes composer in; WordPress (Roots project, some agencies aside) never has, so was never forced to support it. TYPO3 uses composer (with a non-composer option), forcing FAIR to define what composer support means — benefiting everyone. Composer support is "coming to FAIR." #### ⏱️ [01:00:00](https://www.youtube.com/watch?v=czdljy6qrig?t=3600) Non-technical user base and the barrier-to-entry debate - WordPress' wide-open door attracted a "largely non-technical user base" who won't touch a terminal or composer.json. Drupal has the inverse: barrier too high, now courting non-technical "site builders" (config-based middleware roles). - WordPress UI is accessible to everyone; gaps get filled by plugins. FAIR debates whether to require composer knowledge (developer-friendly) or keep a low barrier. #### ⏱️ [01:04:00](https://www.youtube.com/watch?v=czdljy6qrig?t=3840) Site owner vs developer persona - Dils' composer argument: whoever controls updates should be the person who can fix a white-screen — a developer rolling back a tag, not a lost end user clicking "update." - A Pantheon PM floated composer-in-admin (a plugin managing composer files); both are skeptical it'd defeat the purpose. Tools exist (a WP composer plugin; Satis / "status-press" self-hosted repos). Core principle: don't force a site owner to become a developer; a developer can be a site owner. #### ⏱️ [01:08:00](https://www.youtube.com/watch?v=czdljy6qrig?t=4080) Wrap-up - Find Carrie: kydils.com, Bluesky, LinkedIn (a "lurker"), and Post Status chat as C Dils. Thanks and sign-off. ## 📚 References - [FAIR — Federated and Independent Repositories](https://fair.pm/) - [Linux Foundation](https://www.linuxfoundation.org/) - [TYPO3](https://typo3.org/) - [Astro](https://astro.build/) - [Roots (Bedrock / composer for WordPress)](https://roots.io/) - [Satis (composer repository generator)](https://github.com/composer/satis) - [Carrie Dils — kydils.com](https://kydils.com/) - [Patchstack](https://patchstack.com/) · [Wordfence](https://www.wordfence.com/) ## 🗣️ Paraphrase - Carrie Dils' path into WordPress wasn't a straight line: a single college HTML class gave her a freelance web career, she burned out and spent ~a decade at Starbucks, then returned to tech in 2012 when WordPress made building sites feel almost effortless compared to hand-rolling a CMS. - Teaching became central. After her own Lynda.com instructor nudged her, she built courses by learning material deeply enough to explain it — discovering that teaching is itself the most durable way to learn. - The heart of the episode is FAIR, a Linux Foundation-backed, deliberately CMS-agnostic project she co-chairs that gives package management trust signals (provenance and vulnerability verification) WordPress currently lacks — born from the realization that depending on a single controllable repository (WordPress.org) is a real supply chain risk. - FAIR's WordPress adoption has lagged, but its agnostic design is paying off: a March TYPO3 hackathon produced a working implementation headed for TYPO3 core, and TYPO3's composer-native stack is pushing FAIR to add composer support that ultimately helps everyone — even as the community wrestles with serving both non-technical site owners and developers. ## 📰 Newsletter - This week on Community + Code, host Chris Reynolds sits down with WordPress educator and FAIR co-chair Carrie Dils — and it's a treat for anyone who remembers FTPing their "web log" up by hand. Carrie's career runs from a mid-90s HTML elective through a decade at Starbucks to a decade-plus teaching on Lynda.com / LinkedIn Learning. - The gem for builders: teaching *is* learning. Carrie turned book chapters (hat tip Brad Williams) into courses and learned by explaining — proof that the fastest way to lock in a concept is to teach it to someone else. - The big story is FAIR (Federated and Independent Repositories), the Linux Foundation-backed answer to "what if WordPress.org goes dark?" Think trust signals, provenance, and known-vulnerability checks for plugins and themes — the confidence you don't get today when you inherit a site with 34 out-of-date plugins. - Cross-ecosystem energy is real: a March TYPO3 hackathon shipped a working FAIR implementation now heading into TYPO3 core, and TYPO3's composer-native world is finally pushing composer support into FAIR. Plus a look at Cloudflare's new "Mdash" reimagining of WordPress. Find Carrie at kydils.com. ## ✅ Action Items #### DevRel - Developer advocacy: produce a "FAIR trust signals explained" demo showing provenance + vulnerability verification on a real plugin update. - Education: package the teaching-as-learning method into an onboarding workshop ("read it, do it, teach it"). - Developer experience: document FAIR's composer and non-composer install paths with quickstarts mirroring TYPO3's dual approach. - Developer marketing: case-study the TYPO3 hackathon collaboration as proof of FAIR's agnostic value. - Community management: run an office-hours thread on the composer-vs-low-barrier debate to surface contributor consensus. - Internal/external/cross-project: align FAIR TSC, Linux Foundation, and TYPO3 leadership on shared roadmap milestones. #### OSPO - Policy & Governance: document FAIR's three-co-chair model and TSC tiers as a reusable governance template. - License Compliance: define package provenance + signing requirements for FAIR-served artifacts. - Security Management: formalize vuln intake and "no known active vulnerabilities" attestation in the trust-signal spec. - Software Inventory: prototype an SBOM-style manifest for a FAIR package set (the "50 plugins, 34 outdated" scenario). - Developer Support: offer consultation hours on adopting FAIR for non-WordPress CMS communities. - Community Engagement: pursue upstream funding/MoUs after the Yoast-aligned funding setback. - Strategic Alignment: set adoption KPIs given that "widespread WordPress adoption hasn't happened." #### Community - Maintainers: capture the abandoned-maintainer risk (sBlog pattern) in a release-hygiene checklist. - Contributors: create "first issue" rotations for FAIR composer-support work. - Sponsors: publish transparent budgets to avoid repeat funding stalls. - Ecosystem: run a cross-project (WordPress/TYPO3/Drupal) supply-chain disclosure drill. #### WordPress - Core: track FAIR/composer support as a potential future core consideration ("not in core... at least not yet"). - Core Performance: assess plugin-isolation approaches (cf. Cloudflare Mdash) for security/perf tradeoffs. - Core AI: scrutinize "AI builds your site, no CMS needed" claims with evaluation criteria. - Community: feature FAIR/teaching content in WordCamp speaker mentorship. - Training: turn Dils' chapter-to-course method into a learning-path template. - Plugins: pilot trust-signal/provenance checks in the plugin review pipeline. - Hosting: build cross-host checklists for detecting outdated/vulnerable plugins (Pantheon AI-crawler context). - Security: map plugin CVE exposure to a remediation cadence. #### The WPCC - Programs: consider maintainer stipends to reduce abandonment risk. - Projects: host a governance clinic using FAIR's TSC model. - Funding experiments: pilot transparent, milestone-based funding to avoid the buy-in gap that pushed contributors back. ### FAIR - Technical independence: ship local metadata, provenance, and signature checks so sites survive a repository shutdown. - Policies and covenants: codify funding transparency and anti-capture covenants after the 2024 wakeup call. - Productized governance artifacts: publish charters, operator agreements, and the co-chair scorecard for reuse by other communities. ## 🧪 Hypotheses - FAIR adoption will grow faster in CMS communities with composer-native, developer-leaning user bases (TYPO3, Drupal) than in WordPress, whose user base is largely non-technical. - Adding trust signals (provenance + known-vulnerability checks) measurably reduces successful supply-chain compromises of plugins/themes versus auto-updates alone. - Teaching a concept (explaining/producing a tutorial) produces higher long-term retention than passively consuming a video course of the same material. - A single-controlled repository (WordPress.org) is a structural single point of failure; federated repositories reduce the blast radius of a shutdown or capture event. - Plugin isolation architectures (Cloudflare Mdash-style) reduce CVE-driven incidents relative to plugins writing directly to a shared file system. - Requiring composer knowledge as a barrier to entry will suppress non-technical adoption while increasing maintainability for the sites that do adopt. ### 📊 Methodology - Run a controlled A/B on update workflows (FAIR trust signals vs. stock WordPress updates) across a fleet of inherited multi-plugin sites; measure compromise/regression rates. - Longitudinal retention study comparing "consume-only" vs. "consume-then-teach" learners on identical WordPress topics (e.g., i18n), tested at 1 and 6 months. - Cross-CMS adoption cohort tracking FAIR installs/extensions served on WordPress vs. TYPO3 post-hackathon, controlling for community size. - Incident-rate analysis comparing isolated-plugin architectures (Mdash) vs. traditional installs over a fixed window using CVE/exploit telemetry. - Survey FAIR contributors on the composer barrier question; correlate stance with self-identified persona (developer vs. site owner). ### ❓ Questions - What concrete adoption threshold would signal FAIR has "made it" in WordPress, and what's the realistic timeline? - Can composer support land in FAIR without raising the barrier for non-technical site owners — or are those goals fundamentally in tension? - Does cross-CMS collaboration (TYPO3) strengthen FAIR's WordPress case, or does it dilute focus? - How does FAIR's funding model avoid the stall that pushed Yoast-aligned contributors back? - If WordPress.org were turned off tomorrow, how many sites could FAIR realistically keep updating today? ### 🔮 Future Research - Define and benchmark a "trust signal" standard (provenance, signing, vulnerability state) portable across package ecosystems. - Study governance outcomes of multi-chair vs. single-chair open-source projects on decision quality and resilience. - Map the site-owner-vs-developer persona spectrum and design update UX that serves both without forcing role conversion. - Investigate AI-bot-crawler load as a driver of hosting/security architecture decisions. ### 💡 Implications - Practice: agencies and freelancers gain a way to verify package provenance before bulk-updating inherited sites. - Policy: open-source projects can adopt FAIR's Linux Foundation-guided TSC/co-chair governance as a template against capture. - Security: federated repositories plus trust signals shrink the single-point-of-failure and supply-chain attack surface. - Education: the teaching-as-learning model argues for tutorial-production as a core upskilling tactic, not just consumption. - Funding: transparent, milestone-based funding is needed to keep volunteer-driven infrastructure projects alive. ### 🧠 Learning Styles Assessment - Reading level estimate: Flesch-Kincaid Grade ~7–8 (conversational spoken transcript; short clauses, common vocabulary, frequent self-correction and filler). #### 👀 Visual learners - Present: none inherent to an audio/video conversation transcript beyond talking heads. - Improve: add architecture diagrams of FAIR's federated repository flow, a before/after of a package trust signal, and a governance-tier chart. #### 🔊 Aural learners - Present: full podcast/video audio with natural dialogue and narration. - Improve: publish a 2–5 minute audio summary and chapter markers. #### 🗣️ Verbal learners - Present: rich analogies ("slinging coffee," "happy la-la land," "yoloing the update button"), concrete examples (50 plugins/34 outdated). - Improve: add a glossary (FAIR, TSC, composer, Satis, provenance, supply chain). #### 🧩 Kinesthetic learners - Present: implicit step-by-steps (inheriting and updating a site). - Improve: a hands-on lab installing FAIR locally on TYPO3 and WordPress. #### 🧠 Logical learners - Present: cause/effect reasoning on supply-chain risk and the composer persona tradeoff. - Improve: a decision tree for "should this site use composer?" and a RACI for FAIR governance. #### 🧑‍🤝‍🧑 Social learners - Present: a two-person dialogue modeling peer knowledge exchange; mentions of Post Status chat, author summits. - Improve: a discussion-prompt kit and moderated community Q&A. #### 🧘‍♀️ Solitary learners - Present: reflective framing on career nonlinearity. - Improve: self-check questions on supply-chain risk and a journaling prompt on teaching-as-learning. #### 🌿 Naturalistic learners - Present: ecosystem language ("larger open-source ecosystem," "natural gravity"). - Improve: lifecycle framing of plugin maintenance and abandonment. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: this analytical note uses headings and landmarks; the source is a video. - Improve: ensure the published video page has proper heading structure and descriptive labels. #### Keyboard navigation - Present: not applicable to the transcript itself. - Improve: verify the host player offers visible focus and keyboard-operable controls. #### Contrast and readability - Present: not applicable to the source content. - Improve: confirm the video page meets 4.5:1 text contrast. #### Text resizing and reflow - Present: not applicable to spoken content. - Improve: ensure caption rendering reflows at 200% zoom. #### Media and captions - Present: a transcript exists (this processing). - Improve: publish a cleaned, human-corrected caption track and a downloadable transcript; the auto-transcript has garbled names (Morten Rand-Hendriksen, TYPO3) and timestamps. #### Forms and interactions - Present: not applicable. - Improve: ensure any subscribe/comment forms have labels and accessible errors. #### Standards reference - Map caption-quality gaps to WCAG 2.2 AA 1.2.2 (Captions) and 1.2.1 (Audio-only/Video-only). ### 🌍 DEIB Assessment #### Cultural breadth - Present: cross-community examples (WordPress, Drupal/BADCamp, TYPO3) widen perspective beyond one ecosystem. - Improve: include non-US/global open-source community voices and translated FAIR docs. #### Inclusive language - Present: generally plain and gender-neutral; some jargon (TSC, composer, Satis) undefined. - Improve: add plain-language summaries and a glossary. #### Neurodiversity support - Present: conversational chunking and a previewed structure in the intro. - Improve: consistent chapter headings and predictable section patterns in the published version. #### Representation - Present: features a woman developer/educator and FAIR co-chair, plus discussion of non-technical users as legitimate stakeholders. - Improve: balance quoting across the broader FAIR/TSC contributor base (Brent and others named but not heard). #### Psychological safety - Present: respectful framing; deliberately avoids rehashing community "drama," and Dils is candid about FAIR's shortfalls without blame. - Improve: note content context when referencing the 2024 community controversy and link factual background. ### ✅ Logical Validity #### Strong reasoning - Causal (supply chain): "what if somebody turns WordPress.org off... how are we still receiving updates?" — a clear single-point-of-failure argument, strengthened by Dils noting it "literally happened" for a specific audience. Clarify by quantifying affected sites. - Analogical (composer/Drupal): WordPress was "never forced to think about composer" because, unlike Drupal, it isn't composer-native — a sound structural analogy explaining why TYPO3's adoption forces the issue. - Inductive (teaching-as-learning): multiple converging anecdotes (chapter-to-course, i18n, tutorial blogging) support the claim that teaching cements knowledge. Clarify with a study citation. #### Fallacies - Appeal to popularity / bandwagon (mild): "of course everybody is going to sign up" for Cloudflare's free bot protection — popularity asserted, not the tool's merit. Fix: cite adoption data or value, not inevitability. - Hasty generalization: "largely non-technical user base... they're never going to open a terminal" — a reasonable trend stated as near-absolute. Fix: hedge with proportions/segments. - Equivocation risk on "broken/impaired": Reynolds explicitly softens "broken" to "impaired," which is good practice, but the underlying claim about the whole plugin ecosystem stays broad. Fix: scope to outdated/unmaintained plugins specifically. #### Tone of voice - Warm, candid, self-deprecating, and reflective ("happy la-la land," "hurting cats," "everything is hard"); nostalgic about old-web tooling; honest about FAIR's gaps rather than promotional. ### 🛡️ DARVO Analysis - Deny: no DARVO pattern present. Dils does not deny FAIR's shortfalls — she openly states "widespread adoption... hasn't happened" and acknowledges "where FAIR still has ground to cover." - Attack: no attacks on accusers or critics; she explicitly declines to "rehash any drama" from the 2024 community events. - Reverse victim/offender: no role reversal. The 2024 controversy is referenced only as a catalyst, with no attempt to recast any party as victim or villain. Emotional cues are reflective ("appalled and frustrated... wakeup call"), not defensive or accusatory. ## 🎯 Conclusion - Bottom line: Carrie Dils' through-line is that durable expertise comes from teaching, and durable infrastructure comes from not depending on a single controllable repository — FAIR is the institutional answer to the latter, even though WordPress adoption hasn't yet arrived. - FAIR is alive and cross-pollinating: a working TYPO3 implementation headed for core, composer support on the way, and Linux Foundation-backed governance built to resist capture. - Practical next steps for readers: try FAIR locally (WordPress and TYPO3), evaluate trust signals before your next bulk plugin update, watch Cloudflare's Mdash as a convergent take on plugin isolation, and adopt the "read it, do it, teach it" loop to lock in new skills. ## 🔄 Refactor Appendix — Community + Code: Episode 28 - Carrie Dils > 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] Teaching a concept cements your own understanding > [!quote] ID:rw_czdljy6qrig_h1 > "to be able to teach it, you have to understand it thoroughly" **Context & use**: - ~[00:27:00] teaching-as-learning segment. - Argues tutorial production (explain/teach) beats passive consumption for retention; mirrors Dils' tutorial-blog and chapter-to-course practice. **Tags**: #xref #aphorisms **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> #### [H2] FAIR exists in case WordPress.org gets turned off > [!quote] ID:rw_czdljy6qrig_h2 > "what if somebody turns WordPress.org off because we can't control that" **Context & use**: - ~[00:33:00] FAIR origin segment. - Frames the single-point-of-failure supply-chain risk as both technical and business; Dils notes it "literally happened" for a specific audience. **Tags**: #xref **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> #### [H3] Trust signals verify a package's source and safety > [!quote] ID:rw_czdljy6qrig_h3 > "verifying that a package is who it's supposed to be from coming from the destination it's supposed to be from" **Context & use**: - ~[00:39:00] trust-signals segment (the "50 plugins, 34 outdated" scenario). - Captures FAIR's core value: provenance + known-vulnerability verification that WordPress plugins currently lack. **Tags**: #xref **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> #### [H4] Agnostic design lets TYPO3 force composer support into FAIR > [!quote] ID:rw_czdljy6qrig_h4 > "WordPress community have never been forced to think about composer in any sort of real supporting sort of sense" **Context & use**: - ~[00:55:00] composer segment. - A consumer outside WordPress (composer-native TYPO3) surfaces requirements WordPress alone never would; the fix benefits everyone. **Tags**: #xref #articleseed **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates (H4) #### [P1] Don't force a site owner to become a developer **Claim** (one sentence, Courtney's voice): Tooling should let a developer also be a site owner without ever forcing a site owner to become a developer. **Evidence pointer**: [[#H4]] > [!quote] > "you shouldn't force a site owner to become a developer" **Scope & conditions**: Holds for end-user CMS platforms with mixed personas (WordPress); breaks where the entire user base is technical (Drupal site-builders, composer-native stacks) and a higher barrier is acceptable. **Links**: - [[Persona-driven product design]] — because extends - [[Barrier to entry tradeoffs]] — because contrasts on developer-power vs accessibility - [[Composer in WordPress]] — because applies-in update-management UX <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Watch Cloudflare "Mdash" — plugin-isolation architecture as convergent evidence for FAIR's supply-chain thesis — https://www.youtube.com/watch?v=czdljy6qrig #fleeting #inbox - [F2] Open question: what adoption threshold means FAIR has "made it" in WordPress, and by when? #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Install FAIR locally on both WordPress and TYPO3 to compare trust-signal behavior — #things - [ ] Draft article on teaching-as-learning as an upskilling tactic — #things ``` Processed: Community + Code: Episode 28 - Carrie Dils - Literature atoms: 4 / 5 cap - Permanent candidates: 1 / 3 cap - Fleeting items: 2 - Things 3 actions: 2 / 2 cap - Konik tags used: [#xref, #aphorisms, #articleseed] - Triage callouts populated: [Cross Reference, Article Ideas] - Quality gates: [✓ verbatim quotes, ✓ atomicity, ✓ link annotations, ✓ YAML hygiene, ✓ Konik triage, ✓ diff readiness] - Override conditions triggered: [4 Literature atoms — dense source with 4 distinct claims] ``` <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/Community + Code Episode 28 - Carrie Dils.md|Community + Code: Episode 28 - Carrie Dils by youtube.com]] ## Highlights - and to be able to teach it, you have to understand it ([View Highlight](https://read.readwise.io/read/01kvt8cfxx196wxgqngvy0hhx6)) - Note: Teaching cements your own understanding. - Tags: atom/literature/h2 ## Links - [[3. Resources/Permanent Notes/Gate Contributions on Demonstrated Comprehension Not on Tooling]] — evidence-for: teaching exposes whether someone understands the work rather than merely operating its tools. - [[3. Resources/Permanent Notes/Casual Contributors Are Users Not Community Members]] — applies-in: site-owner workflows shouldn't require developer identity or Composer expertise. - WordPress community have never been forced to think about composer in any ([View Highlight](https://read.readwise.io/read/01kvt8cm4bxz3j5baahq92071p)) - Note: FAIR's agnostic design forces composer support. - Tags: atom/literature/h3 - shouldn't force a site own you shouldn't force a site owner to become a developer ([View Highlight](https://read.readwise.io/read/01kvt8cja2h077xpjfa29pkzaf)) - Note: Persona principle: don't make site owners developers. - Tags: atom/literature/h2