Open source has a big AI slop problem 🔗 **Source:** [Open source has a big AI slop problem](https://leaddev.com/software-quality/open-source-has-a-big-ai-slop-problem) > [!note]+ Document Notes > tags: [open-source, AI, software-quality] > author: Kari McMahon > source: LeadDev > reference: [https://leaddev.com/software-quality/open-source-has-a-big-ai-slop-problem] > date created: 2026-02-17 10:00 > > # 🏷️ Title: Open source has a big AI slop problem > <!-- 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 - Include links cited in or relevant to the article. ## 📝 Summary - What happened: Maintainers of major open-source and adjacent projects are being flooded with low-quality, AI-generated “slop” in PRs and security reports, forcing them to change contribution and governance models. - Why it matters: Reviewer time, burnout, and security signal-to-noise are all getting worse, pushing platforms like GitHub to add new controls and projects to tighten their processes. - Key stakeholders: Open-source maintainers (cURL, RubyGems, WordPress), platforms (GitHub), agencies (Fueled), dev tool builders (tldraw), universities, and aspiring contributors. - Risks and tradeoffs: Tighter gates and trust networks reduce slop but may exclude juniors and new voices; shifting from code to “problem definition” work could erode deep implementation skills over time. - Bottom line: The ecosystem must redefine what counts as a “contribution,” add guardrails for AI usage, and invest in governance, tests, and education so AI helps maintainers instead of overwhelming them. ## 📖 Main Content - The article defines **AI slop** as low-quality, often unsolicited generative AI output—now appearing as huge PRs and dubious security reports. This overwhelms maintainers who must triage large volumes of code and claims that often misunderstand the underlying problem or solution. - WordPress and other projects are creating **AI usage guidelines**, including disclosure requirements and anti-slop norms (e.g., no giant code dumps). The aim is not to ban AI but to ensure humans stay accountable for understanding and testing the changes they submit. - cURL’s bug bounty program was swamped by AI-written vulnerability reports, with only ~5% valid, forcing the project to shut the program and move to more controlled channels. RubyGems is considering a similar move after months without a valid report. - Maintainer **burnout** is intensifying: reviewing AI slop can consume a full day that used to take minutes, especially for sensitive security reports that only a handful of trusted maintainers can review. - tldraw, while not fully open source, had to **close external PRs** after a wave of AI-generated contributions from people who never completed CLAs or followed up, prompting GitHub to design new features (limiting who can open PRs, hiding PR UI, etc.) that give maintainers more control. - Experts debate responses: monetary deposits, trust networks, stricter CLAs, or shifting contributor work from code-authoring to **problem identification and definition**, while maintainers wield AI to implement fixes. Each option risks sidelining junior developers and shrinking the pipeline of future maintainers. - GitHub notes that “contribution” is still overly tied to **code authorship**, highlighting WordPress’s practice of giving “props” for non-code work (writing, reproduction steps, testing, support) as a better model for an AI-heavy future. - Some AI slop may be benign (students chasing résumé lines), but there are concerns about **supply chain attacks** by accounts using AI to cheaply simulate a track record of helpful PRs before slipping in malicious changes. - AI can also **combat slop**: strong automated tests in cURL’s CI help filter bad PRs instantly; AI analyzers have already helped cURL fix 100+ bugs. A more robust testing culture and AI-augmented CI can act as a throttle on low-quality AI output. - A final perspective is economic: current AI tools are “too cheap,” encouraging massive, low-effort experimentation. Introducing real costs for usage could dampen misaligned incentives to spray AI-generated contributions across projects. ### 🗒️ Notes - AI slop = low-quality, error-prone, unrequested generative AI output flooding open-source workflows via PRs and vuln reports. - WordPress publishes AI guidelines: require disclosure of AI use, discourage large automated code dumps, and clarify expectations to protect maintainer capacity. - cURL’s bug bounty: AI-written reports grow throughout 2025; only ~5% valid; program closed, shifting to email/GitHub for security reports. - Vulnerability triage is high-context, low-bus-factor work; small trusted teams (like cURL’s seven maintainers) shoulder the load, making spam particularly costly. - RubyGems sees a 10x increase in reports, almost all invalid; maintainer time for review explodes from minutes to full days. - Intel’s community survey: documentation/onboarding and burnout are top pain points; AI slop amplifies burnout by making work feel like “fighting a machine.” - tldraw: many PRs appear polished but are obviously AI-authored; contributors don’t complete CLAs or engage in review, indicating low investment and understanding. - To cope, tldraw scripts automatic closure of external PRs—effectively implementing hard gates before GitHub offers native controls. - GitHub responds with new platform features: allow projects to limit who can create PRs, disable PRs, or hide PR UI; more changes planned after consultation. - Maintainers frame these controls not as closing open source but as acknowledging projects have **never** been able to absorb all contributions at scale. - Proposals like monetary deposits and trust networks may reduce spam but clash with open-source values of accessibility and transparency, and risk excluding junior devs. - Ruiz suggests reframing contribution: community members identify and specify issues; maintainers then apply AI tools to implement fixes, leveraging their deeper codebase knowledge. - Risk: if maintainers monopolize implementation and AI handles much of the coding, fewer people gain the deep understanding needed to become senior maintainers or reviewers. - GitHub points to models like WordPress “props” where non-code work is recognized, foreshadowing a broader definition of contribution in an AI era. - Universities and gatekeeping institutions lag behind reality: they still treat GitHub contribution graphs as strong signals, ignoring how easily AI can automate “contributions.” - CLAs and more onerous contributor processes can double as **AI slop detection** signals when contributors fail to respond or follow through. - AI can also be part of the solution via better test coverage, CI checks, and static analyzers: cURL’s AI-powered code analyzers have already surfaced and helped fix 100+ bugs. - Economic argument: if AI usage carries more direct cost, there will be less incentive for low-effort, high-volume “spray and pray” contribution attempts. ## 📚 References - Kari McMahon, “Open source has a big AI slop problem” (LeadDev, 2026-02-17) — https://leaddev.com/software-quality/open-source-has-a-big-ai-slop-problem - GitHub blog on upcoming contribution controls and maintainer tools (referenced in article) — https://github.blog - WordPress project, AI usage guidelines and contributor “props” practices — https://make.wordpress.org - Daniel Stenberg on cURL security process and AI reports — https://curl.se - Ruby Central / RubyGems security and vulnerability reporting practices — https://rubygems.org - Intel Open Source Community Survey (documentation, onboarding, burnout data) — https://www.intel.com/content/www/us/en/developer/topic-technology/open.html - tldraw project and contributor license agreement model — https://www.tldraw.com ## 🗣️ Paraphrase - Paragraph A paraphrase: The article argues that generative AI is flooding open-source projects with poorly understood, low-quality contributions that look helpful but often aren’t, significantly increasing review and security workloads for already-stretched maintainers. - Paragraph B paraphrase: In response, projects and platforms are tightening contribution rules, redefining what counts as meaningful participation, and exploring both governance and technical defenses so AI augments open source instead of overwhelming it. ## 📰 Newsletter In this week’s WordPress DevOps Dispatch, we zoom out from the latest plugin releases to a growing ecosystem headache: **AI slop**. LeadDev’s coverage of cURL, RubyGems, and WordPress shows how low-quality AI PRs and vuln reports are burning out maintainers and forcing new guardrails. For WordPress builders, this is a chance to get ahead: - Audit your repos’ contribution guidelines and mirror the emerging **AI disclosure norms** from Core. - Double down on **automated tests and CI** so bogus AI patches fail fast. - Recognize non-code work—bug reproduction, support, docs—the same way WordPress Core gives “props.” Helpful jumping-off points: WordPress contributor handbooks (https://make.wordpress.org), GitHub’s evolving maintainer tools (https://github.blog), and accessible test tooling in the WP ecosystem (e.g., Playwright + WP-Env, WP-CLI-based smoke tests). AI can still be a force multiplier—but only if we treat governance and review capacity as first-class features of our projects. ## ✅ Action Items #### DevRel - **Developer advocacy**: Create talks and blog posts on “responsible AI contributions” with concrete PR examples; track reduction in rejected AI slop over 3–6 months. - **Education**: Run workshops on writing good issue reports, repro steps, and tests; include a unit on how (and when) to use AI coding tools. - **Developer experience**: Provide example PR templates with AI usage disclosure, checklist for tests/docs, and minimal diff guidelines. - **Developer marketing**: Campaign around “contribute beyond code” highlighting user testing, docs, and triage contributions; measure signups and retention of new contributors. - **Community management**: Update codes of conduct and contribution guides to cover AI misuse; monitor and report trends in abusive or spammy AI-driven behavior. - **Internal/external/cross-project**: Coordinate with major upstream projects (WordPress, PHP, Linux distros) to align AI policies and share spam/attack patterns. #### OSPO - **Policy & Governance**: Draft AI contribution policies: disclosure, banned behaviors (e.g., unreviewed dumps), escalation paths, and decision rights for closing PRs/bug bounties. - **License Compliance**: Extend license review processes and training to cover AI-generated code, model terms, and provenance obligations. - **Security Management**: Create clear vuln intake channels with rate limits and triage guidelines; consider separate paths for trusted reporters vs. anonymous/AI-heavy reports. - **Software Inventory**: Include AI usage metadata in SBOMs (e.g., components touched by AI-assisted changes) and define update freshness targets. - **Developer Support**: Offer consultation hours on AI-assisted workflows, from secure coding patterns to CI integration of AI analyzers. - **Community Engagement**: Fund upstream projects affected by AI slop (e.g., cURL, RubyGems) via sponsorships tied to security and governance work. - **Strategic Alignment**: Set KPIs for reduced maintainer burnout, improved triage throughput, and successful adoption of AI-aware contribution practices; report quarterly to leadership. #### Community - **Maintainers**: Host roadmap and governance clinics focused on AI-era contribution rules, PR gating, and security disclosure processes. - **Contributors**: Build onboarding paths that start with issue triage, docs, and tests before code changes; run “first issue” rotations emphasizing understanding over code volume. - **Sponsors**: Publish transparent budgets for work on tests, CI, and moderation tools that mitigate AI slop; tie milestones to measurable improvements in signal-to-noise. - **Ecosystem**: Coordinate incident drills and disclosure practices across related projects to respond to AI-accelerated supply chain risks. #### WordPress - **Core**: Prioritize backlogs that improve test coverage and CI performance; clarify release criteria around review of AI-assisted changes. - **Core Performance**: Define metrics to monitor performance regressions tied to AI-originated patches; consider performance bounties for test improvements. - **Core AI**: Establish responsible AI guardrails for code generation, including evaluation sets and red lines (e.g., no unreviewed code dumps into Core). - **Core Program Team**: Add AI-risk checkpoints to release retrospectives; ensure cross-team dependencies (Docs, Security, Hosting) are covered. - **Mobile**: Review telemetry for AI-driven bug patterns; improve offline UX testing to avoid AI-generated fixes that regress constrained environments. - **Playground**: Provide labs and reproducible environments where contributors can safely test AI-generated patches against realistic WordPress stacks. - **Community**: Add meetup and WordCamp content on responsible AI contribution; share scripts and moderation patterns for handling AI slop. - **Training**: Create learning paths on “Contributing with AI responsibly,” including exercises on writing tests and small, reviewable patches. - **Marketing**: Shape narratives around WordPress as a leader in sustainable, human-centered AI contribution practices. - **Support**: Update support escalation paths and SLAs to handle increased AI-generated bug reports; flag patterns of automated noise. - **Design**: Audit UX around contribution flows in .org tools to gently steer users toward smaller, higher-quality contributions. - **Documentation**: Maintain guidance on best practices for AI use in WordPress development; provide examples-first patterns and anti-patterns. - **Photos**: Tighten moderation for AI-generated media submissions, ensuring provenance, licensing, and quality fit the project’s needs. - **TV**: Encourage talks and screencasts on AI-assisted workflows with clear safeguards; ensure captions highlight key practices. - **Polyglots**: Coordinate on how AI translation tools are used and reviewed; clarify quality expectations and glossary alignment. - **Accessibility**: Treat AI-generated UI/UX proposals skeptically; run them through WCAG-aligned reviews and automated tooling. - **Meta**: Improve .org infra reliability and contributor tools to support higher-volume but higher-quality participation; add anti-spam features. - **CLI**: Provide AI-friendly scaffolds and commands that encourage tests, docs, and small diffs by default. - **Hosting**: Collaborate on default server configs and tooling that surface quality, security, and provenance metrics for plugins/themes. - **Tide**: Explore AI-aware scoring to detect low-quality generated code; set up loops to handle false positives. - **Openverse**: Ensure ingestion pipelines and moderation policies cover AI-generated assets and provenance metadata. - **Themes**: Offer lints and mentoring for authors using AI to generate code, enforcing security and performance standards. - **Plugins**: Strengthen provenance checks and peer review for AI-heavy submissions; add security liaison touchpoints. #### The WPOCC - **Programs**: Design fellowship tracks and stipends for maintainers focusing on tests, CI, and governance under AI pressure. - **Projects**: Run documentation and governance sprints to craft model AI contribution policies for WordPress-adjacent projects. - **Funding experiments**: Pilot microgrants and matched grants for AI-aware moderation tooling, automated test suites, and contributor education. ### FAIR - **Technical independence**: Track provenance of AI-generated patches; consider local metadata and signatures on critical repos. - **Policies and covenants**: Publish funding transparency for AI tooling vendors; define anti-capture and sunset clauses for experimentation. - **Productized governance artifacts**: Create reusable charters, operator agreements, and scorecards to help projects evaluate and adopt AI responsibly. ## 🧪 Hypotheses - H1: Requiring AI usage disclosure and limiting PR size will measurably reduce AI slop in open-source projects without significantly lowering valid contributions. - H2: Projects with high test coverage and strong CI will experience less harmful impact from AI-generated PRs than similar projects with weaker testing. - H3: Recognizing non-code contributions (docs, testing, triage) will diversify contributor roles and lessen pressure to submit AI-generated code for résumé building. - H4: Implementing stricter contribution controls (e.g., PR gating, CLAs) will disproportionately reduce participation from junior developers relative to seniors. - H5: Increasing the marginal cost of AI tool usage will decrease the volume of low-quality automated vulnerability reports. ### 📊 Methodology - For H1: Run a before/after observational study on multiple repos that adopt AI disclosure rules and PR size limits; compare rates of rejected PRs, maintainer review time, and valid contributions. - For H2: Correlate test coverage metrics and CI strictness with incidents of AI slop in matched sets of projects; use regression to control for size and popularity. - For H3: Track contribution mix (code vs. non-code) and contributor retention across projects that adopt formal recognition for non-code work vs. those that don’t. - For H4: Analyze contribution histories, seniority proxies (tenure, role), and PR acceptance rates before/after introducing stricter gates; supplement with contributor surveys. - For H5: Use natural experiments where AI pricing changes; measure changes in volume and quality of AI-like vulnerability reports over time. ### ❓ Questions - How can projects balance the need for strong gates against AI slop with their mission to be open and welcoming to new contributors? - What metrics best capture “maintainer burnout” and how directly can they be tied to AI-driven workload? - Can we reliably detect AI-generated contributions at scale without harming privacy or stigmatizing legitimate AI-assisted work? - How should universities update their evaluation criteria to account for AI-automated contribution patterns? - What governance patterns work best for distinguishing high-trust from low-trust contributors without centralization or gatekeeping abuse? ### 🔮 Future Research - Longitudinal studies on how AI tools reshape contributor pipelines and the maintainer “pyramid.” - Experiments on alternative bug bounty models resilient to AI spam (e.g., vetted researchers, trusted tiers, or structured templates). - Economic modeling of AI pricing, usage incentives, and their impact on spammy vs. high-value contributions. - Development and evaluation of AI tools specialized in **triaging** other AI-generated reports and PRs. - Research into provenance and attestation mechanisms that are usable by volunteer-driven open-source projects. ### 💡 Implications - **Practice**: Teams must adopt clearer contribution guidelines, mandatory review processes for AI changes, and robust tests to keep workloads sustainable. - **Policy**: Foundations and OSPOs should craft shared policies on AI contributions, security disclosures, and recognition of non-code work. - **Security**: AI slop both obscures real vulnerabilities and can be used to build credibility for supply chain attacks; security teams should adapt intake and trust models. - **Education**: Curricula should emphasize problem understanding, testing, and ethics around AI, not just “shipping PRs.” - **Funding models**: Sponsors may need to fund governance, moderation, and test infrastructure as core security work, not overhead. ### 🧠 Learning Styles Assessment - **Reading level estimate**: Roughly college/early professional level (approx. Flesch–Kincaid Grade 12–14) due to domain jargon and multi-clause sentences. #### 👀 Visual learners - Present: Standard web layout, headings, and some visual hierarchy. - Improve: Add diagrams of the contribution funnel, flows of AI slop vs. valid reports, and before/after PR gating scenarios. #### 🔊 Aural learners - Present: No explicit audio or podcast version mentioned. - Improve: Offer a short audio summary or TTS button, plus a podcast segment discussing maintainer experiences. #### 🗣️ Verbal learners - Present: Clear definitions (e.g., AI slop), quotes from experts, and concrete examples. - Improve: Add analogies (e.g., spam email vs. inbox rules) and a short glossary for non-specialist readers. #### 🧩 Kinesthetic learners - Present: None directly. - Improve: Provide checklists or small exercises (e.g., rewrite a bad AI PR into a good one) and sample contribution templates. #### 🧠 Logical learners - Present: Cause–effect chains (AI use → volume → burnout), some statistics (5% valid reports). - Improve: Include simple charts, tables comparing interventions, and explicit decision trees for maintainers. #### 🧑‍🤝‍🧑 Social learners - Present: Perspectives from multiple stakeholders (maintainers, OSPOs, platforms). - Improve: Add discussion prompts, community forum links, or guided group reading questions. #### 🧘‍♀️ Solitary learners - Present: Article format supports focused, individual reading. - Improve: Include reflection questions at the end and a short self-check quiz. #### 🌿 Naturalistic learners - Present: Limited direct connection to environment or sustainability. - Improve: Use ecosystem metaphors (e.g., invasive species for AI slop) and discuss sustainability of maintainer labor. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Likely standard headings and paragraphs via CMS. - Improve: Ensure proper heading hierarchy, descriptive alt text, and language attributes. #### Keyboard navigation - Present: Standard article page likely navigable via keyboard. - Improve: Confirm visible focus states, add skip-to-content links, and avoid interactive traps in overlays or banners. #### Contrast and readability - Present: Typical tech blog contrast (likely adequate but unverified). - Improve: Validate 4.5:1 contrast, check line height and paragraph spacing, and avoid dense text blocks. #### Text resizing and reflow - Present: Responsive design likely supports zoom and mobile. - Improve: Confirm reflow at 200% zoom, minimize horizontal scrolling, and honor prefers-reduced-motion. #### Media and captions - Present: Primarily text; minimal media. - Improve: For any embedded video, ensure captions and transcripts; avoid autoplay. #### Forms and interactions - Present: Account/login or subscription prompts may be present. - Improve: Ensure labels, clear error states, large hit targets, and accessible notification messaging. #### Standards reference - Map gaps to WCAG 2.2 AA criteria including 1.4.x (contrast), 2.1.x (keyboard), 1.4.10 (reflow), 3.3.x (input assistance), and 2.3.3/2.2.6 (motion/time-based media and reduced motion). ### 🌍 DEIB Assessment #### Cultural breadth - Present: Focus on Western-centric open-source communities but touches broad OSS ecosystem. - Improve: Include examples from non-Western or underrepresented open-source communities and how AI slop affects them. #### Inclusive language - Present: Generally neutral, professional tone; limited jargon is explained. - Improve: Add plain-language summaries and avoid assuming deep prior knowledge of open-source governance. #### Neurodiversity support - Present: Logical structure with headings and quotes. - Improve: Increase chunking, add summary boxes, and keep layout predictable with minimal distractions. #### Representation - Present: Quotes a mix of maintainers and OSPO leaders, but no explicit demographic diversity is highlighted. - Improve: Intentionally quote a broader range of contributors, including juniors and people from diverse regions. #### Psychological safety - Present: Respectful framing of contributors, even when criticizing AI slop; no shaming. - Improve: Explicitly address that mistakes (including misusing AI) are learning opportunities and should be handled constructively. ### ✅ Logical Validity #### Strong reasoning - The article uses **causal reasoning**: increased AI usage → increased low-quality reports → higher maintainer workload → burnout and governance changes. Cited percentages (e.g., 5% valid reports, Intel survey numbers) support these links. - It uses **inductive reasoning** from multiple case studies (cURL, RubyGems, tldraw, WordPress, GitHub) to argue that AI slop is systemic, not isolated. - To strengthen further, it could include more systematic data (time logs, longitudinal stats) rather than relying mostly on expert testimony. #### Fallacies - Potential **hasty generalization** risk: limited number of project anecdotes may not represent all of open source. This is mitigated somewhat by varied examples, but explicit caveats about scope would help. - Some speculative comments (e.g., “tin foil hat” supply chain concerns) verge on **appeal to fear**; balancing them with concrete evidence or stating them clearly as hypotheses would improve rigor. #### Tone of voice - Tone is pragmatic and mildly alarmed but not sensationalist. It mixes narrative quotes (“tsunami,” “fighting a machine”) with balanced commentary on tradeoffs and potential solutions. ### 🛡️ DARVO Analysis - **Deny**: The article does not deny the existence of AI slop or its impacts; it surfaces maintainer complaints directly. - **Attack**: There is no attack on maintainers or critics; language toward AI slop contributors is critical but framed as often misguided rather than malicious. - **Reverse victim/offender**: The piece does not portray offenders as victims; instead, it highlights maintainers as bearing the brunt of the problem while acknowledging that some contributors are students or under-informed. - Overall, the article does not exhibit DARVO patterns; it seeks to diagnose a problem and explore responses rather than deflect responsibility. ## 🎯 Conclusion The article argues that generative AI is reshaping open-source collaboration by flooding maintainers with low-quality, often context-free contributions, particularly in security reporting and PRs. In response, projects and platforms are experimenting with new governance models, contribution controls, and better testing to safeguard human time and security. For readers, practical next steps include: clarifying AI usage guidelines in your projects, investing in automated tests and CI, recognizing non-code contributions, and advocating for institutional (university, employer, foundation) norms that value understanding and stewardship over raw PR counts. --- ## 🧱 Refactor Appendix ### 📚 Literature Split Pad - Purpose: Stage Konik CEE units that become per-source Literature notes. - Split level: **H3**. - Include verbatim quotes under 25 words and a [view highlight] link. ### [H1] AI slop overwhelms open-source maintainers > [!quote] [Open source has a big AI slop problem](https://leaddev.com/software-quality/open-source-has-a-big-ai-slop-problem) by [[Kari McMahon]] via [[LeadDev]]. Published 2026-02-17. Accessed 2026-02-17. > “AI slop is generally folks who either don’t understand the core problem, the solution crafted, or both.” Two lines: context and use. Cite data if relevant. [view highlight](https://leaddev.com/software-quality/open-source-has-a-big-ai-slop-problem#H1) #xref #articleseed ID:rw_[MISSING] ### [H2] Platforms add controls to combat AI slop > [!quote] [Open source has a big AI slop problem](https://leaddev.com/software-quality/open-source-has-a-big-ai-slop-problem) > “GitHub… introducing changes that will provide maintainers with more control… including the option to limit who can submit pull requests.” Two lines: context and use. [view highlight](https://leaddev.com/software-quality/open-source-has-a-big-ai-slop-problem#H2) #xref ID:rw_[MISSING] --- ### 🔖 Atomic Split Pad (Zettel Candidates) - Purpose: Promote reusable claims into Atomic notes. - Split level: **H4**. - Each item: one idea, present tense, specific, testable. #### [Z1] Strong tests mitigate AI slop in PRs - When projects have robust automated tests, AI-generated PRs that break behavior are quickly filtered out. - Pointer to article’s cURL example. - Links: [[AI-in-open-source]] [[Test-Infrastructure]] #### [Z2] Contribution definitions must expand beyond code - Recognizing non-code work reduces pressure to submit AI-generated code for status. - Pointer to WordPress “props” example. - Links: [[Contribution-Governance]] [[Community-Health]] --- ### ✏️ Fleeting Queue (Extract by Selection) - Purpose: Capture quick actions or sparks for Fleeting notes. - Extraction: **Select one line** → “Refactor: Extract selection to new note (content only).” - Keep each line short and self-contained. - [F1] Draft AI usage guidelines for my repos modeled on WordPress and GitHub controls — context/https://leaddev.com/software-quality/open-source-has-a-big-ai-slop-problem #fleeting #inbox - [F2] Evaluate current bug bounty intake for susceptibility to AI slop and propose guarded channels — context/https://leaddev.com/software-quality/open-source-has-a-big-ai-slop-problem #fleeting #inbox - [F3] Design a workshop on “contributing with AI responsibly” for junior developers — context/https://leaddev.com/software-quality/open-source-has-a-big-ai-slop-problem #fleeting #inbox --- <!-- deep-read:sections end -->