The Checklist That Keeps Open Source Projects Alive ![rw-book-cover](https://i.ytimg.com/vi/-QKLHKo5SxY/sddefault.jpg) 🔗 **Source:** [The Checklist That Keeps Open Source Projects Alive](https://www.youtube.com/watch?v=-QKLHKo5SxY) > [!note]+ Document Notes > tags: [open-source, oss-sustainability, community-building, maintainership, contributor-experience, governance] > author: [MISSING] > source: All Things Open (YouTube) > reference: https://www.youtube.com/watch?v=-QKLHKo5SxY > date created: 2026-06-28 09:00 > > # 🏷️ Title: The checklist that keeps open source projects alive > <!-- 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 - [All Things Open conference](https://www.allthingsopen.org/) - [AlmaLinux project](https://almalinux.org/) — speaker's project, cited as a no-CLA example - [Open Source Initiative — approved licenses](https://opensource.org/licenses) - [Contributor Covenant](https://www.contributor-covenant.org/) — code-of-conduct baseline - [GitHub issue & PR templates](https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests) ## 📝 Summary - **What happened.** A maintainer (working on AlmaLinux) delivered a people-focused ATO talk: a "before you start" checklist for small open-source projects about to invite outside contributors, plus the things that matter most once newcomers arrive. - **Why it matters.** Most sustainability advice is technical (CI/CD, infra). This talk argues the failure mode for small projects is human — ego, undefined expectations, and burnout — not tooling. - **Key stakeholders.** Solo and small-team maintainers, prospective contributors, project leadership/governance, and the broader OSS ecosystem that depends on these projects surviving. - **Risks and tradeoffs.** Inviting feedback without emotional and time readiness "goes poorly." CLAs protect the project but deter contributors. AI contributions raise provenance and trust questions. Single-maintainer projects are a single point of failure. - **Bottom line.** Decide your goal, get an outside eval, drop your ego, define feedback channels and realistic timelines, use templates, set an AI/CLA policy, build leadership beyond yourself, find a partner, and take care of yourself — or don't ask for feedback yet. ## 📖 Main Content - **The premise is "people are hard," not "code is hard."** The speaker explicitly separates this from the CI/CD talks common at events like ATO and stays in the human lane: receiving opinions you wouldn't otherwise encounter, which the talk frames as net-good for the project and ecosystem. - **Stated assumptions scope the advice.** Aimed at small projects (solo or small group), already (or soon) OSI-licensed, where the maintainer already wants feedback and has — or will make — time for the work. The talk treats projects that haven't done this work as making a valid, non-judged choice. - **Define your goals first.** Contributors? Code reviewers? Bug fixes / feature work? Or just more users? Goal selection drives where you focus effort. - **Get an outside evaluation.** Can a stranger find the code, understand setup, know how to interact with you, and read your expectations? Is the audience clear? Is setup documented? The maintainer is "the hardest one" to do this honestly. - **The hardest step is ego.** Newcomers will disagree, with and without valid reasons. "Let go of your ego immediately." If you can't reach the point where disagreement is okay, you're not ready for feedback — and that's fine, just don't ask for it. - **Define feedback channels "quickly and loudly."** Chat server vs. GitHub issues vs. separate places for bugs and feature requests — make it clear and discoverable, or people won't follow the process (and may not even when it is clear). You're allowed to redirect politely. - **Templates everywhere.** They make it easy for contributors to supply exactly the info you need, and give you consistent feedback. - **Set and honor realistic reply timelines.** A two-week reply is fine if communicated; silence against an unstated expectation reads as being ignored. Consistency builds trust; inconsistency ("up to 10 days" but always 1) breaks it. - **Set explicit AI and CLA policies.** AI isn't going away; decide how you handle AI-assisted contributions. Use caution, know training-data provenance, never obfuscate your own AI use, and always fact-check. On CLAs: they protect the project but deter contributors who won't sign over rights; AlmaLinux doesn't need one given how it builds. - **Build leadership beyond yourself.** Past a certain size you need a decision/communication structure. Don't be a single point of failure. - **Sustain yourself.** Strive for grace and humility under public scrutiny; if it stops being fun, reconsider; find a partner early to stay energized and out of a silo; engaging many people is draining, so take care of yourself. - **Uncertainties / contested claims.** The CLA stance is project-specific (AlmaLinux's build model), not universal. "AI is always present now" is asserted, not evidenced. The whole framework is offered as "one ideal scenario," not the only path. ### 🗒️ Notes #### ⏱️ [00:00:00](https://www.youtube.com/watch?v=-QKLHKo5SxY?t=0) Framing — opening up to outside opinions - Goal of the talk: help you open your project to opinions that are hard to encounter day to day. - Core belief: more opinions than people, and those opinions are good for the project and the ecosystem. #### ⏱️ [00:01:30](https://www.youtube.com/watch?v=-QKLHKo5SxY?t=90) Assumptions that scope the advice - You know what OSS is; you're solo or a small team; focus is smaller projects. - You're (or soon) OSI-licensed; you already want feedback; you have or will make time. - "People are hard" — this is a people talk, explicitly not CI/CD. Treats it as one ideal path, no judgment on projects that skipped it. #### ⏱️ [00:04:00](https://www.youtube.com/watch?v=-QKLHKo5SxY?t=240) Define your goals - Contributors, code reviewers, bug/feature workers, or more users — pick the goal to focus effort. #### ⏱️ [00:05:00](https://www.youtube.com/watch?v=-QKLHKo5SxY?t=300) Outside evaluation of the project as-is - Can a newcomer find code, setup, your interaction norms, your expectations? Clear audience? Documented setup? You're the hardest evaluator. #### ⏱️ [00:06:30](https://www.youtube.com/watch?v=-QKLHKo5SxY?t=390) The ego step — hardest of all - People will disagree with and without valid reasons; that's okay. Let go of ego now. - If you can't accept feedback, don't ask for it — "I promise you it's going to go poorly." #### ⏱️ [00:08:30](https://www.youtube.com/watch?v=-QKLHKo5SxY?t=510) Feedback channels, templates, timelines - Define feedback paths quickly and loudly; redirect politely when misplaced. - Templates everywhere → consistent, copy-paste-ready reports. - Communicate realistic reply times; consistency = trust, inconsistency = broken trust. #### ⏱️ [00:12:00](https://www.youtube.com/watch?v=-QKLHKo5SxY?t=720) AI policy and fact-checking - Decide how AI-assisted contributions are handled; AI is present and not going away. - Know training-data provenance; never obfuscate AI use; always fact-check ("never been to the moon"). #### ⏱️ [00:14:30](https://www.youtube.com/watch?v=-QKLHKo5SxY?t=870) CLA tradeoff and leadership - CLA protects the project but deters some contributors; AlmaLinux doesn't need one. - Build group leadership; don't be a single point of failure. #### ⏱️ [00:17:00](https://www.youtube.com/watch?v=-QKLHKo5SxY?t=1020) Grace, fun, partnership, self-care - Strive for grace and humility; watch yourself when you want to "flip the table." - If it's not fun, reconsider; find a partner early; engaging many people drains you — take care of yourself. ## 📚 References - [All Things Open](https://www.allthingsopen.org/) — host conference (ATO) - [AlmaLinux](https://almalinux.org/) — speaker's project; cited as a no-CLA example - [Open Source Initiative](https://opensource.org/licenses) — OSI-approved license requirement referenced in assumptions - [Contributor Covenant](https://www.contributor-covenant.org/) — code-of-conduct ops baseline - [GitHub: issue and PR templates](https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests) — the "templates are your friends" mechanism - [CHAOSS — community health metrics](https://chaoss.community/) — measurement frame for the talk's trust/engagement themes ## 🗣️ Paraphrase - Opening a project to the public means inviting opinions you'd never meet otherwise, and that's a feature: more viewpoints make the project and the ecosystem stronger. This talk is deliberately about people, not pipelines. - Before you open the doors, pick a concrete goal, have someone outside test whether your project is even approachable, and — hardest of all — set your ego down so disagreement doesn't wreck you. If you can't do that, don't ask for feedback yet. - Once newcomers arrive, make your feedback channels obvious, lean on templates, and promise reply times you can actually keep, because trust is built or broken on consistency. - Decide your AI and CLA policies on purpose, fact-check everything, build leadership so you're not a single point of failure, find a partner, and protect your own energy — because if it stops being fun, something is wrong. ## 📰 Newsletter **The kindest checklist in open source isn't about your code.** This ATO talk from an AlmaLinux maintainer skips the CI/CD greatest hits and goes straight for the thing that actually sinks small projects: people. The throughline for WordPress folks is uncomfortably familiar — half of "contributor experience" is just defining expectations out loud and then honoring them. Make the feedback path loud, [ship issue and PR templates](https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests), promise reply windows you'll keep, and treat your own ego as the first dependency to patch. The AI bit lands too: decide your policy, never obfuscate your use, and fact-check — because the model tells you the *most likely* truth, not the true one. WordPress contributor teams looking to onboard new humans (Training, Docs, Polyglots, the whole make.wordpress.org family) could lift this wholesale. Bonus reminder, free of charge: if it's not fun anymore, that's data, not a character flaw. Find a partner, set up leadership beyond yourself, and take care of yourself like the project depends on it — because it does. ## ✅ Action Items #### DevRel - Developer advocacy: turn the checklist into a "before you open contributions" talk/demo for WP component leads; measure via new-contributor first-PR time. - Education: run an office-hours session on writing issue/PR templates and contributor expectations. - Developer experience: audit one project's onboarding as a literal stranger; log every place a newcomer gets stuck. - Developer marketing: publish a "define your goals" worksheet (contributors vs. reviewers vs. users) as a contributor-funnel asset. - Community management: codify reply-time SLAs in CONTRIBUTING and the code of conduct ops. - Internal/external/cross-project: align feedback-channel definitions and SLAs across the projects you advise. #### OSPO - Policy & Governance: template a contribution policy that names decision rights and a "not a single point of failure" leadership clause. - License Compliance: document an AI-contribution provenance policy (training-data origin, no obfuscation). - Security Management: tie AI-assisted code review into vuln intake and attestation. - Software Inventory: note AI-generated components in SBOM ownership. - Developer Support: stand up consultation hours on CLA-vs-no-CLA tradeoffs for project leads. - Community Engagement: fund the partner/co-maintainer model the talk recommends. - Strategic Alignment: add "bus factor > 1" and "documented escalation path" as OSPO KPIs. #### Community - Maintainers: run a governance-template clinic; require a defined feedback channel before "good first issue" labels go live. - Contributors: build a first-issue rotation with templates pre-filled. - Sponsors: tie funding milestones to documented governance and reply-time consistency. - Ecosystem: cross-project drill on consistent contributor expectations. #### WordPress - Core: publish triage reply-time expectations on key components. - Core Performance: template perf-regression reports so feedback arrives in a consistent shape. - Core AI: define an AI-contribution provenance + fact-check policy mirroring the talk. - **Core Program Team:** add a "single point of failure" check to component-lead retrospectives. - Mobile: document the contributor onboarding path as a stranger would hit it. - Playground: ship reproducible-bug templates as education modules. - Community: fold "define your goals + self-care" into meetup organizer kits. - Training: build a "open your project for feedback" lesson on Learn WordPress. - Marketing: narrative on people-first sustainability, not just tooling. - Support: set and publish response SLAs; review for consistency. - Design: audit contributor-facing flows for "can a newcomer find this." - Documentation: examples-first CONTRIBUTING with explicit expectations and channels. - Photos: clarify submission expectations and reply cadence. - TV: caption-quality + submission-guide expectations stated up front. - Polyglots: translation-sprint templates with clear glossary expectations. - Accessibility: review contributor docs for WCAG and plain-language clarity. - Meta: ship issue/PR templates across .org tooling repos. - CLI: scaffold a CONTRIBUTING + templates generator command. - Hosting: cross-host contributor-expectation checklist. - Tide: state scoring expectations and false-positive review loop clearly. - Openverse: provenance + AI policy for ingested content contributions. - Themes: template review feedback for consistency; mentor on expectations. - Plugins: provenance checks for AI-assisted submissions. #### The WPCC - Programs: maintainer stipends conditioned on co-maintainer / bus-factor goals. - Projects: governance clinics using this checklist as the spine. - Funding experiments: matched grants for projects that document channels, SLAs, and leadership. ### FAIR - Technical independence: provenance and signature checks for AI-assisted contributions. - Policies and covenants: anti-single-point-of-failure and funding-transparency clauses. - Productized governance artifacts: a "before you open contributions" charter + scorecard. ## 🧪 Hypotheses - **H1.** Projects that publish a defined feedback channel and reply-time SLA get higher-quality first contributions than those that don't. - **H2.** Projects using issue/PR templates have lower maintainer triage time per issue than template-less projects. - **H3.** Maintainers who report "I let go of my ego" handle critical feedback with fewer abandoned threads / locked issues. - **H4.** Projects with ≥2 maintainers (bus factor > 1) have higher 3-year survival than solo projects. - **H5.** Explicit AI-contribution policies reduce contentious AI-related PR disputes. - **H6.** Maintainers who report "still having fun" have lower 12-month burnout/attrition than those who don't. ## 📊 Methodology - **H1/H2.** Natural experiment across a sample of GitHub repos: code presence/absence of CONTRIBUTING channels, SLA text, and `.github` templates; measure first-PR quality (review rounds, merge rate) and median triage time. Control for project age, stars, language. - **H3/H6.** Maintainer survey + sentiment coding of issue threads; correlate self-reported ego/fun measures with thread-resolution and contributor-retention metrics (CHAOSS). - **H4.** Longitudinal cohort using bus-factor estimation (commit/ownership distribution) vs. archived/active status at 36 months. - **H5.** Diff-in-diff around adoption dates of AI-contribution policies vs. count of contentious AI PR threads. ## ❓ Questions - Where exactly is the readiness line between "ego in check" and "not ready for feedback," and can it be self-assessed reliably? - Do reply-time SLAs help more by setting expectations or by forcing maintainer discipline? - What's the minimum viable governance structure that removes single-point-of-failure risk without overhead? - How should AI-contribution provenance actually be verified in practice, not just stated? - Does the no-CLA stance generalize beyond AlmaLinux's build model? ## 🔮 Future Research - A validated "contributor-readiness" self-assessment instrument for maintainers. - Comparative study of CLA vs. DCO vs. no-CLA effects on contributor inflow and project protection. - Burnout-prevention interventions (partner model, leadership distribution) with measured outcomes. - Tooling that detects "single point of failure" repos and nudges co-maintainer recruitment. ## 💡 Implications - **Practice.** Onboarding is mostly expectation-setting; ship channels, templates, and SLAs before recruiting contributors. - **Policy.** AI and CLA decisions should be explicit project artifacts, not ad-hoc reactions. - **Security.** AI-assisted contributions need provenance + fact-check gates tied to review. - **Education.** "Open your project for feedback" is a teachable curriculum, distinct from CI/CD training. - **Funding models.** Sponsors and OSPOs can condition support on bus-factor > 1 and documented governance — turning sustainability from a vibe into a checklist. ### 🧠 Learning Styles Assessment - Reading level estimate: Flesch-Kincaid ~ grade 8–9 (conversational, spoken-word transcript with short clauses and repetition); Flesch Reading Ease ~ 65–70 (fairly easy). #### 👀 Visual learners - Present: none — audio-only transcript, no slides captured in text. - Improve: publish the checklist as a one-page graphic; add a readiness decision tree and a before/after onboarding diagram. #### 🔊 Aural learners - Present: native audio/video conference talk with natural narration. - Improve: 3-minute audio recap of the checklist; chaptered audio. #### 🗣️ Verbal learners - Present: strong — analogies ("templates are your friends"), the moon fact-check joke, plain-language framing. - Improve: add a glossary (CLA, OSI license, single point of failure, bus factor). #### 🧩 Kinesthetic learners - Present: implicit "get someone to evaluate your project" hands-on step. - Improve: turn the talk into a fill-in worksheet and a repo self-audit lab. #### 🧠 Logical learners - Present: ordered checklist structure (goals → eval → ego → channels → AI/CLA → leadership → self-care). - Improve: add a RACI for leadership distribution and a decision table for CLA/AI choices. #### 🧑‍🤝‍🧑 Social learners - Present: the partner/co-maintainer recommendation; community framing throughout. - Improve: discussion prompts and a peer-review rubric for contributor docs. #### 🧘‍♀️ Solitary learners - Present: reflective "be honest with yourself" self-check moments. - Improve: journaling prompts on readiness and burnout signals. #### 🌿 Naturalistic learners - Present: ecosystem framing ("good for our ecosystem in general") and sustainability metaphor. - Improve: lifecycle/health-of-a-project framing with CHAOSS ecosystem metrics. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: N/A for spoken talk; depends on the YouTube page structure. - Improve: ensure the published transcript uses real headings/landmarks and descriptive link text. #### Keyboard navigation - Present: N/A to the talk itself; applies to the hosting page. - Improve: verify YouTube embed controls and any companion slides are keyboard reachable with visible focus. #### Contrast and readability - Present: unknown (no slides in transcript). - Improve: if slides exist, hold 4.5:1 text contrast and large, legible type. #### Text resizing and reflow - Present: transcript reflows as plain text. - Improve: publish transcript in a 200%-zoom-safe layout without clipping. #### Media and captions - Present: a transcript exists (this file); video likely has auto-captions. - Improve: human-corrected captions, a downloadable transcript, and audio descriptions of any on-screen slides; no autoplay. #### Forms and interactions - Present: N/A. - Improve: any companion contribution forms should have labels, inline validation, and adequate target size. #### Standards reference - Map gaps to WCAG 2.2 AA: 1.2.2 Captions, 1.2.5 Audio Description, 1.4.3 Contrast, 1.4.10 Reflow, 2.4.4 Link Purpose, 2.4.7 Focus Visible. ### 🌍 DEIB Assessment #### Cultural breadth - Present: globally relevant OSS framing; no region-locked examples. - Improve: add non-US/non-English contributor scenarios and translation links for CONTRIBUTING docs. #### Inclusive language - Present: warm, plain, non-gendered ("get someone," "a partner"); jargon mostly defined in context. - Improve: define CLA/OSI/bus-factor explicitly for newcomers; avoid idioms like "flip the table" without gloss. #### Neurodiversity support - Present: chunked, repetitive, predictable checklist structure aids processing. - Improve: explicit headings and icon+text labels in the published version; consistent template patterns. #### Representation - Present: speaker centers maintainer and contributor perspectives evenhandedly. - Improve: include varied contributor identities and accessibility-of-contribution paths in examples. #### Psychological safety - Present: strong — repeated "that's okay," non-judgment of projects that skipped the work, explicit permission to not ask for feedback if not ready. - Improve: pair with concrete code-of-conduct escalation paths and moderated Q&A guidance. ### ✅ Logical Validity #### Strong reasoning - **Causal (ego → bad outcomes):** "If you can't get to the point where you can take that feedback... just don't ask for it. I promise you it's going to go poorly." A plausible causal claim grounded in maintainer experience; clarify by citing patterns of locked/abandoned threads. - **Inductive (consistency → trust):** the "up to 10 days but always 1 day" example generalizes a trust mechanism from a concrete case; strong because it's falsifiable and observable. - **Analogical (templates as friends):** maps templates to reduced contributor effort; strong because the mechanism (copy-paste-ready info) is explicit. #### Fallacies - **Hasty generalization** — "make yourself not a single point of failure... very rarely is there an exception." Location: leadership segment. Weakness: asserts near-universality from experience without data. Fix: cite bus-factor survival studies or soften to "most long-lived projects distribute leadership." - **Appeal to novelty / inevitability** — "[AI] is always something that is going to be present at this point like it's not going away." Location: AI segment. Weakness: treats current ubiquity as permanent inevitability. Fix: frame as "for the foreseeable future" and tie policy to provenance, not inevitability. - **False dilemma (soft)** — readiness framed as "can take feedback" vs. "don't ask for it." Location: ego segment. Weakness: omits middle paths (limited-scope feedback, moderated intake). Fix: acknowledge graduated openness. #### Tone of voice - Warm, encouraging, candid, self-deprecating (the moon joke), and permission-giving. Repeated "that's okay" sets a low-shame, high-safety register; occasional informal repetition typical of live speech. ### 🛡️ DARVO Analysis - **Deny:** None. The speaker doesn't deny wrongdoing or minimize criticism; the opposite — she normalizes receiving criticism. - **Attack:** None. No attacks on critics or contributors; disagreement is framed as legitimate ("with and without valid reasons... that's okay"). - **Reverse victim/offender:** None. No recasting of the accused as victim. If anything, the talk pre-empts maintainer defensiveness by naming ego as the obstacle. - Emotional cues are supportive, not defensive; no DARVO pattern present. Not applicable beyond this note. ## 🎯 Conclusion - **Bottom line.** Keeping a small open-source project alive is mostly a people problem: define your goal, get an honest outside read, drop your ego, make feedback channels and reply times explicit and consistent, set deliberate AI and CLA policies, distribute leadership so you're not the single point of failure, find a partner, and protect your own energy. If you can't accept feedback yet, don't ask for it. - **Next steps for readers.** Pick one project, audit its onboarding as a stranger, ship issue/PR templates plus a reply-time SLA, write a one-line AI policy, and name a second maintainer or a partner this quarter. ## 🔄 Refactor Appendix — The checklist that keeps open source projects alive > 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. ### 📚 Literature Atoms (H3) #### [H1] Open source surfaces more opinions than people > [!quote] ID:rw_h1 > "We know that there are more opinions than there are people most times. And we want we want those opinions because they're good for us." **Context & use**: - Opening framing (~00:00). - Reframes "too many opinions" as the value, not the cost, of opening a project. **Tags**: #xref #aphorisms **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> #### [H2] Ego is the hardest barrier to receiving feedback > [!quote] ID:rw_h2 > "You need to let go of your ego immediately. And if you really want your project to succeed, because there are going to be people that come in and disagree with you with and without valid reasons for doing so." **Context & use**: - Ego segment (~00:06:30), named the hardest step. - Gate: if you can't drop ego, don't invite feedback yet. **Tags**: #xref #aphorisms **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> #### [H3] Templates make contributor feedback consistent > [!quote] ID:rw_h3 > "Templates are going to be your friends. Use them everywhere that you possibly can" **Context & use**: - Process segment (~00:09). - Mechanism: copy-paste-ready info → consistent, usable reports. **Tags**: #xref #addendum **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> #### [H4] AI returns the likely truth, not the actual truth > [!quote] ID:rw_h4 > "And remember, AI is is going to tell you the most likely truth, not necessarily the actual truth." **Context & use**: - AI policy segment (~00:13), followed by the moon-joke fact-check. - Justifies an always-fact-check rule for AI-assisted work. **Tags**: #xref #aphorisms **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> #### [H5] Distribute leadership to avoid a single point of failure > [!quote] ID:rw_h5 > "make yourself not a single point of failure and set up some kind of uh leadership that isn't just you." **Context & use**: - Governance segment (~00:15). - Core sustainability claim: bus factor > 1. **Tags**: #xref **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> #### [H6] If it stops being fun, reconsider the work > [!quote] ID:rw_h6 > "If you're not having fun, seriously reconsider how it's work working because it's too life is too short for you to not have be having fun." **Context & use**: - Self-care close (~00:17:30). - Frames fun as a burnout signal, not a luxury. **Tags**: #xref #aphorisms **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates (H4) #### [P1] Maintainer readiness is emotional capacity, not tooling **Claim** (one sentence, Courtney's voice): A small open-source project's readiness to accept contributors is gated by the maintainer's capacity to receive disagreement, not by its infrastructure. **Evidence pointer**: [[#H2]] **Scope & conditions**: Holds for solo/small-team projects inviting outside feedback; breaks for large projects with mature governance where process buffers individual ego. **Links**: - [[Contributor experience]] — because extends - [[Open-source governance]] — because applies-in distributing decision rights - [[Burnout in maintainership]] — because contrasts on sustainability dimension <!-- atomicity: 1 idea ✓ --> #### [P2] Stated-and-honored expectations build contributor trust **Claim** (one sentence, Courtney's voice): Contributor trust is built by defining expectations explicitly and then meeting them consistently, more than by speed. **Evidence pointer**: [[#H3]] **Scope & conditions**: Holds wherever feedback channels and reply times can be published; breaks if maintainer can't sustain the stated cadence. **Links**: - [[Service-level expectations]] — because applies-in community ops - [[Issue and PR templates]] — because evidence-for <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Build a one-page "before you open contributions" checklist graphic from this talk — #fleeting #inbox - [F2] Find the speaker's social post with the full recommendations list (she said she'd share it) — https://www.youtube.com/watch?v=-QKLHKo5SxY #fleeting #inbox - [F3] Compare AlmaLinux's no-CLA stance against DCO-based WP project norms — #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Draft a Learn WordPress lesson "Open your project for feedback" from this checklist — #things - [ ] Add reply-time SLA + AI-provenance lines to a CONTRIBUTING template — #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/The Checklist That Keeps Open Source Projects Alive.md|The Checklist That Keeps Open Source Projects Alive by youtube.com]] ## Highlights - But I'm going to be talking to you about how you can open your project up for opinions that [clears throat] might not be the easiest to en encounter in your everyday life because we know what open source is like. We know that there are more opinions than there are people most times. And we want we want those opinions because they're good for us. They're ([View Highlight](https://read.readwise.io/read/01kw82km6g01kahmeskp62jp89)) - Note: Framing: more opinions than people in OSS — and that diversity of opinion is a feature, not a bug. - Tags: open-source, community-building, atom/literature/h2 - succeed, because there are going to be people that come in and disagree with you with and without valid reasons for doing so. And that's okay. If you can't get to the point where that's okay, then you're not ready to receive feedback. And that's fine, right? We we have that like personal investment in the project that we care about. If you can't get to the point where you can take that feedback, that's okay. Just don't ask for it. I promise you it's going to go poorly. Be honest with yourself about whether or ([View Highlight](https://read.readwise.io/read/01kw82kewqa5qga53y3sen5tgp)) - Note: Readiness to receive feedback = precondition for opening a project. If you can't accept disagreement, don't ask for feedback. - Tags: open-source, atom/literature/h1, contributor-experience - you so much." Remember, they're investing their time in giving you feedback, but also you're allowed to say, "This isn't the way I want to be interacted with." Templates are going to be your friends. Use them everywhere that you possibly can because then as a contributor, it's a way easier for me to say, "I found this bug. This is all the information you're asking for, and I can just like copy and paste everything in there that you need, right?" You'll get consistent feedback in the way that you want it when you use templates. Set uh and ([View Highlight](https://read.readwise.io/read/01kw82kv3pt74fnycjhqzagn3y)) - Note: Templates as a contributor-experience lever — consistent, lower-friction feedback for both sides. - Tags: open-source, contributor-experience, atom/literature/h3 - do. If you're doing like a marketing thing and you're getting AI to help you write a blog post, fact check, fact check. I think all of us in here know this, but always, always, always fact check. And remember, AI is is going to tell you the most likely truth, not necessarily the actual truth. Because despite what chat GBT told me two years ago, I have never been to the moon. Promise. [laughter] Um, to CLA or not CLA, you saw both ([View Highlight](https://read.readwise.io/read/01kw82m1qk1pcmssmk1cxmfcqz)) - Note: Zettel: "AI tells you the most likely truth, not necessarily the actual truth." Always fact-check. - Tags: atom/zettel/z1, open-source - I'm I'm going to tell you very rarely is there an exception. So make yourself not a single point of failure and set up some kind of uh leadership that isn't just you. I have flown through this, right? But there's a lot of recommendations and I don't want to miss you want you to miss out on anything. So I will actually share these on my social so you can find them there if you didn't get to them. Um, remember if you're clear with yourself about what you want to accomplish, you ([View Highlight](https://read.readwise.io/read/01kw82m80cwfavv35f2q85mt3w)) - Note: Bus-factor / governance: don't be a single point of failure; build leadership that isn't just you. - Tags: governance, open-source, atom/literature/h2 - it's going to be fun. If you're not having fun, seriously reconsider how it's work working because it's too life is too short for you to not have be having fun. find a partner, especially early on, because then you're not in a a silo and you have somebody else that not necessarily holds you accountable, but I always find that if I'm talking to somebody else about something, I'm going to be more excited about it. I'm going to be more engaged. Even if nobody else is coming around to want to contribute, at least we've got each other to talk about stuff and like renew your energy ([View Highlight](https://read.readwise.io/read/01kw82mfb9v61fketae8pj6507)) - Note: Maintainer sustainability: if it's not fun, reconsider; find a partner early to avoid the silo. - Tags: atom/literature/h3, open-source, maintainership