# Drupal Contribution Gates — Conversation Context

**Purpose:** Everything needed to continue this conversation in a new session, with a new agent, or with a different human. This is a structured explanation artifact — the kind we're arguing Drupal should adopt.

**Last updated:** March 25, 2026, DrupalCon Chicago

---

## The Core Question

How should Drupal evaluate contributions in an era where AI dramatically lowers the cost of producing code but not the cost of reviewing it?

## Two Positions (Not Opposed)

### Dries Buytaert's Position
- Blog post: [Never Submit Code You Don't Understand](https://dri.es/never-submit-code-you-do-not-understand)
- Standard: "Be able to explain what it does, why it works, and how it interacts with the rest of the code"
- Intent: Signal deliberate effort toward quality. Not a literal verification gate — an honor system meant to set cultural expectations
- Welcoming: "Everyone starts somewhere. You are welcome here, with or without AI tools."
- Problem correctly identified: AI creates [asymmetric pressure](https://dri.es/ai-creates-asymmetric-pressure-on-open-source) — cheaper to submit, not cheaper to review

### Our Position (Zivtech / Alex Urevick-Ackelsberg)
- We agree with Dries's goal: quality contributions, not slop
- We propose infrastructure that makes "own your code" verifiable and scalable
- Four proposed ADRs: quality gates, structured explanation artifacts, scaled review, evidence-based trust
- Key insight: cultural norms don't catch bad-faith actors or honest mistakes. Infrastructure does.
- Broader point: the comprehension standard implicitly requires the person who *sees* the answer to also single-handedly *produce* the formal proof — this excludes contributors whose bottleneck is execution, not understanding

## Key Sources (Read These)

| Source | URL | Key Takeaway |
|--------|-----|--------------|
| "Never Submit Code You Don't Understand" | https://dri.es/never-submit-code-you-do-not-understand | The standard we're building on — own your code, respect maintainers' time |
| "AI Creates Asymmetric Pressure" | https://dri.es/ai-creates-asymmetric-pressure-on-open-source | The problem: review capacity is the bottleneck. curl's 1-in-20 legit submission rate |
| "The Third Audience" | https://dri.es/the-third-audience | AI agents as first-class audience for Drupal content. Content negotiation, markdown discovery |
| "Why Drupal Is Built for the AI Era" | https://dri.es/why-drupal-is-built-for-the-ai-era | Drupal's entity API, config management, and machine-readable APIs make it uniquely AI-ready |
| "Drupal's AI Roadmap for 2026" | https://dri.es/drupal-ai-roadmap-for-2026 | 8 AI capabilities, 28 orgs, 23+ FTEs. Background agents, governance, multi-channel campaigns |
| DrupalCon Chicago 2026 Driesnote | https://events.drupal.org/chicago2026/session/keynote-driesnote | ECA demo (90K lines, 6 weeks, AI-assisted). 22 AI agents out of the box. Native MCP support |
| Policy Brief v2 | https://zivtech.github.io/zivtech-demos/policy-brief-drupal-contribution-gates-v2.html | The collaborative "yes, and" version with 4 ADRs |
| Policy Brief v1 | https://zivtech.github.io/zivtech-demos/policy-brief-drupal-contribution-gates.html | The adversarial first draft (preserved as illustration) |

## Community Feedback on v1 (March 25, 2026)

**Gábor Hojtsy:** Too long. Doesn't think Dries's position is as blocking or contradictory as v1 framed it.

**Jamie (yautja_cetanu):** Initially skeptical, but found "fun and interestingly inciteful points." Recommended reframing as "interesting thoughts based on what Dries said" rather than a rebuttal.

**Dries Buytaert (direct response):**
- "The PDF does mis-categorize me. It says 'contributors must not rely on AI to contribute', but that is not what I said."
- He encourages AI use but wants quality, not slop
- "'Contributor claims understanding' doesn't guarantee high quality... it simply means to signal that the contributor made a deliberate effort to ensure the work is high quality, to the best of their ability"
- Our analysis took his position "too literal"

**catch (Nathaniel Catchpole):** "This would, according to the ADR, make LLMs required for core contribution." Valid concern — addressed in v2 update: ADR-003 now explicitly makes gates and handoff docs optional for non-AI contributors.

**What changed in v2:** Reframed from rebuttal to "yes, and." Killed the contradiction timeline. Led with shared ground. Reframed ADRs as building on Dries's criteria. Cut ~40% length. After catch's feedback: ADR-003 rewritten to make gates optional, not mandatory.

## The Four Proposed ADRs

1. **ADR-001: "Own Your Code" Means Demonstrable Quality** — Supplement the cultural norm with verifiable criteria (tests, security, standards, explanation artifact)
2. **ADR-002: Structured Explanation Artifacts** — Encode Dries's three criteria (what, why, how) in a persistent, queryable format
3. **ADR-003: Gate Critics and Handoff Documents Are Optional for Non-AI Contributors** — AI-assisted contributors encouraged to run local gates and submit handoff docs. Human contributors keep working as today — no new requirements. Addresses catch's concern that gates must not make LLMs required. Like PHPCS: the standard exists, tooling helps, nobody forced to use a specific tool
4. **ADR-004: Trust Earned Through Demonstrated Quality** — Tiered review based on track record, not tenure. Gives newcomers a concrete path in

## Evidence That Quality Gates Work

- **ECA Workflow Editor:** 90K lines, 6 weeks, full test coverage, AI-assisted. Dries celebrated this in the driesnote
- **Zivtech NCLC Digital Library:** Planner-critic pipeline in CI/CD on every PR. 9+ plan revisions caught before implementation
- **skills.sh ecosystem:** Community-built contribution-quality tooling (TDD, security review, coding standards)
- **This conversation itself:** v1 drafted, published, critiqued, revised to v2 in hours — demonstrating the rapid iteration quality gates enable

## Open Questions for Continuing the Conversation

1. **What does the standardized handoff document look like concretely?** YAML metadata? A markdown template? An extension to the existing change record format? It needs to be producible by any AI tool and consumable by any reviewer
2. **Which 2-3 core subsystems would be best for a pilot?** Ideally high-volume, well-tested areas where we can measure gate effectiveness
3. **How do existing tools (DrupalCI, PHPCS, PHPStan) map to the local gates?** Contributors can run these locally today — what's the gap between "run locally" and "include results in a standardized handoff"?
4. **How does Dries's "earn trust through results" (from the asymmetric pressure post) map to ADR-004?** He may already agree with tiered trust — the question is the mechanism
5. **Can we produce an example handoff document for a real Drupal core issue?** A concrete example would be more persuasive than any amount of description

## Who's Involved

- **Alex Urevick-Ackelsberg** (CEO, Zivtech; [alex-ua on drupal.org](https://www.drupal.org/u/alex-ua)) — co-author of the brief (with Claude)
- **Dries Buytaert** — Drupal project lead, author of the original posts, engaged directly with v1
- **Gábor Hojtsy** — Drupal core committer, provided feedback on v1
- **Jamie (yautja_cetanu)** — community member, provided feedback on v1
- **Scott Falconer** — maintains drupal-intent-testing, drupal-contribute-fix; Zivtech contributed to his skills at DrupalCon

## How to Use This Context

If you're an AI agent picking this up in a new session:
1. Read this file first for the full picture
2. Read the v2 brief for the current state of the argument
3. Read Dries's "Never Submit" and "Asymmetric Pressure" posts for his position
4. The open questions above are the next productive directions
5. The tone should be collaborative — "yes, and" not adversarial

If you're a human joining the conversation:
1. Read v2 of the brief (it's shorter)
2. The core proposal: quality gates that make "own your code" verifiable
3. Dries has engaged and his feedback is constructive — he's not opposed to the goal
4. The next step is a concrete pilot proposal