PR triage gate for overwhelmed OSS maintainers
A CI gate that scores and filters low-effort/AI-dumped PRs before they consume open-source maintainer review time.
I want to build a small, bootstrappable product. Help me plan and start the MVP.
Product: PR triage gate for overwhelmed OSS maintainers
What it is: A CI gate that scores and filters low-effort/AI-dumped PRs before they consume open-source maintainer review time.
Who pays: Maintainers and engineering leads at funded open-source projects and foundations (e.g., projects like Plotly, QGIS-scale, or corporate OSS offices) with an infrastructure/community budget, paying $200–800/mo for CI add-ons.
Closest alternatives: CodeRabbit, GitHub Copilot code review, Greptile, human triage / stale-bot automation
The gap: Existing AI reviewers review code quality; none act as a maintainer-side contribution gate that enforces a project's declared AI policy, flags low-effort/unverifiable submissions, and requires submitter-side proof (repro, test, video walkthrough) before any human time is spent.
Why now: The LLM contribution flood is a 2025–26 phenomenon: major projects (QGIS now, others considering) are enacting blanket bans as a stopgap precisely because no tooling exists to ration reviewer attention, and maintainers publicly say they'd rather keep contributing open if filtering were cheap.
Moat to build toward: Policy-as-code rule sets tuned per project plus accumulating labeled data on low-effort vs. genuine contribution patterns across many repos; workflow lock-in once embedded in a project's merge pipeline.
A ready-to-paste brief for Claude Code, Cursor or any coding agent.
The case for
- EX.1QGIS formally bans AI contributions because AI PR volume exceeds human review capacity and erodes reviewer trust.From the article ↗
- EX.2Plotly maintainer describes 3-page unproofread AI issue writeups and plausible-but-weak PRs consuming reviewer time, tempting them to abandon passer-by contributions.Read the comment ↗
- EX.3Commenter explains the volume asymmetry: AI lets low-effort contributors generate content 100x faster than maintainers can evaluate it, most of it subtly bad.Read the comment ↗
- EX.4The bottleneck has shifted from writing code to verifying alignment — staying confident a change does what was intended — which is worst for stranger PRs.Read the comment ↗
The LLM contribution flood is a 2025–26 phenomenon: major projects (QGIS now, others considering) are enacting blanket bans as a stopgap precisely because no tooling exists to ration reviewer attention, and maintainers publicly say they'd rather keep contributing open if filtering were cheap.
The case against
The LLM contribution flood is new, measured, and pushing major projects to blanket bans, and existing AI reviewers review code rather than enforce a maintainer-side contribution policy — a real gap, though monetizing OSS maintainers remains the weak link.
Policy-as-code rule sets tuned per project plus accumulating labeled data on low-effort vs. genuine contribution patterns across many repos; workflow lock-in once embedded in a project's merge pipeline.
Existing AI reviewers review code quality; none act as a maintainer-side contribution gate that enforces a project's declared AI policy, flags low-effort/unverifiable submissions, and requires submitter-side proof (repro, test, video walkthrough) before any human time is spent.
Build it in 3 steps
- 1Build a GitHub Action that scores incoming PRs on effort signals (tests included, linked issue, repro steps, author history, diff/PR-size ratio, AI-style heuristics) and auto-requests missing proof before human review.
- 2Ship a policy config file (YAML) so projects declare their AI/contribution policy and the gate enforces it with configurable thresholds.
- 3Pilot free with 3–5 mid-size OSS projects, publish before/after maintainer review-time data, then charge for team dashboards and org-wide rollout.