✓ ÜberlebtNr. 2 von 3IndieDevTools

PR-Triage-Gate für überlastete OSS-Maintainer

Ein CI-Gate, das wenig durchdachte oder mit KI erzeugte PRs bewertet und filtert, bevor sie die Review-Zeit von Open-Source-Maintainern binden.

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.

Diskussion öffnen ↗

Ein fertiges Briefing für Claude Code, Cursor oder jeden anderen Coding-Agenten (auf Englisch).

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.
Biggest risk: Detection of AI authorship is unreliable, so the product collapses to a fancy CI linter and buyers churn once incumbents bundle a similar gate into GitHub for free.

First three steps:
1. Build 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.
2. Ship a policy config file (YAML) so projects declare their AI/contribution policy and the gate enforces it with configurable thresholds.
3. Pilot free with 3–5 mid-size OSS projects, publish before/after maintainer review-time data, then charge for team dashboards and org-wide rollout.

Start by asking me up to five questions about constraints (stack, budget, timeline), then propose the smallest version a paying customer would use, and scaffold it.

6.1von 10

Was dafür spricht

Wer zahltMaintainer und Engineering Leads finanzierter Open-Source-Projekte und Stiftungen (z. B. Projekte in der Größenordnung von Plotly oder QGIS) sowie Open-Source-Büros in Unternehmen, mit Infrastruktur- oder Community-Budget. Zahlungsbereitschaft: 200 bis 800 US-Dollar pro Monat für CI-Erweiterungen.

Was die Leute sagten

Sinngemäß aus der Diskussion wiedergegeben. Die Links führen zu den Originalkommentaren.

Warum jetzt

Die Flut an LLM-Beiträgen ist ein Phänomen von 2025 und 2026. Große Projekte wie QGIS verhängen inzwischen pauschale Verbote als Übergangslösung, weil es keine Werkzeuge gibt, um die Aufmerksamkeit der Reviewer zu steuern. Maintainer sagen öffentlich, sie würden gern offen für Beiträge bleiben, wenn sich das Filtern günstig umsetzen ließe.

Was dagegen spricht

✕ Woran es scheitern würdeKI-Autorschaft lässt sich nur unzuverlässig erkennen. Das Produkt degeneriert dann zu einem aufgemotzten CI-Linter, und Kunden springen ab, sobald GitHub ein ähnliches Gate kostenlos einbaut.

Der stärkste Einwand des Red Teams

Die Flut an LLM-Beiträgen ist neu, messbar und treibt große Projekte zu pauschalen Verboten. Bestehende KI-Reviewer prüfen Code, erzwingen aber keine Beitragsrichtlinie auf Maintainer-Seite. Das ist eine echte Lücke, wobei die Monetarisierung bei OSS-Maintainern die schwache Stelle bleibt.

Burggraben 4/10

Projektspezifische Regelwerke als Policy-as-Code und wachsende, gelabelte Daten zu wenig aufwendigen gegenüber echten Beiträgen über viele Repositories hinweg. Nach der Integration in die Merge-Pipeline eines Projekts entsteht Bindung an den Workflow.

Was es schon gibt

CodeRabbitGitHub Copilot code reviewGreptilehuman triage / stale-bot automation

Die Lücke

Bestehende KI-Reviewer prüfen Codequalität. Keiner wirkt als Gate auf Maintainer-Seite, das eine deklarierte KI-Richtlinie des Projekts durchsetzt, wenig aufwendige oder nicht überprüfbare Einreichungen markiert und vor jedem menschlichen Review einen Nachweis verlangt, etwa Reproduktion, Test oder Video-Walkthrough.

In 3 Schritten bauen

1GitHub Action bauen, die eingehende PRs anhand von Aufwandssignalen bewertet (Tests vorhanden, verknüpftes Issue, Reproduktionsschritte, Autorenhistorie, Verhältnis von Diff zu PR-Größe, KI-Stil-Heuristiken) und fehlende Nachweise anfordert, bevor ein Mensch prüft
2Eine YAML-Konfigurationsdatei bereitstellen, in der Projekte ihre KI- und Beitragsrichtlinie festlegen, die das Gate mit konfigurierbaren Schwellenwerten durchsetzt
3Kostenlos mit 3 bis 5 mittelgroßen OSS-Projekten pilotieren, Daten zur Review-Zeit vorher und nachher veröffentlichen und danach Team-Dashboards und unternehmensweiten Rollout kostenpflichtig anbieten

Ursprüngliche Diskussion“QGIS enacts moratorium on AI contributions” ↗377 Punkte, 405 KommentareAus der StoryVerlinkter Artikel

Aus dem Englischen übersetzt. Original lesen

PR-Triage-Gate für überlastete OSS-Maintainer

Was dafür spricht

Was dagegen spricht

In 3 Schritten bauen

Mehr aus dieser Ausgabe