Filtre de tri des PR pour les mainteneurs open source débordés
Une étape CI qui note et filtre les PR à faible effort ou générées en masse par IA avant qu'elles ne consomment le temps de revue des mainteneurs open source.
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.
Un brief prêt à coller dans Claude Code, Cursor ou tout agent de code (en anglais).
Les arguments pour
- EX.1QGIS interdit officiellement les contributions IA parce que le volume de PR générées dépasse la capacité de revue humaine et érode la confiance des relecteurs.Tiré de l'article ↗
- EX.2Un mainteneur de Plotly décrit des rapports de bug générés par IA de trois pages non relues, et des PR plausibles mais faibles qui consomment le temps des relecteurs et poussent à abandonner les contributions ponctuelles.Lire le commentaire ↗
- EX.3Un commentateur explique l'asymétrie de volume : l'IA permet aux contributeurs à faible effort de produire cent fois plus vite que les mainteneurs ne peuvent évaluer, et la plupart de ces productions sont subtilement mauvaises.Lire le commentaire ↗
- EX.4Le goulot d'étranglement s'est déplacé de l'écriture du code vers la vérification de son alignement, c'est-à-dire la certitude qu'un changement fait ce qui était prévu, et c'est pire pour les PR d'inconnus.Lire le commentaire ↗
L'afflux de contributions générées par LLM est un phénomène de 2025-2026. De grands projets (QGIS aujourd'hui, d'autres en réflexion) adoptent des interdictions générales par défaut, faute d'outils pour rationner l'attention des relecteurs. Des mainteneurs disent publiquement qu'ils préféreraient garder leur projet ouvert si le filtrage était peu coûteux.
Les arguments contre
L'afflux de contributions LLM est nouveau, mesuré, et pousse de grands projets vers des interdictions générales. Les revueurs IA existants analysent le code plutôt qu'ils n'appliquent une politique de contribution côté mainteneur : c'est un vrai manque, même si la monétisation auprès des mainteneurs open source reste le maillon faible.
Des ensembles de règles en policy-as-code, ajustés pour chaque projet, et des données étiquetées accumulées sur les contributions à faible effort et les contributions sérieuses à travers de nombreux dépôts. Une fois intégré au pipeline de fusion d'un projet, l'outil crée un verrouillage fort.
Les revueurs de code IA existants évaluent la qualité du code. Aucun ne joue le rôle de filtre côté mainteneur qui applique la politique IA déclarée par un projet, signale les soumissions à faible effort ou non vérifiables, et exige des preuves côté auteur (reproduction, tests, vidéo de démonstration) avant qu'un humain n'y consacre du temps.
La construire en 3 étapes
- 1Développer une GitHub Action qui note les PR entrantes sur des signaux d'effort (tests inclus, ticket lié, étapes de reproduction, historique de l'auteur, ratio taille du diff et de la PR, indices de style IA) et demande automatiquement les preuves manquantes avant la revue humaine
- 2Livrer un fichier de configuration YAML pour que chaque projet déclare sa politique IA et de contribution, et que le filtre l'applique avec des seuils configurables
- 3Proposer un pilote gratuit à 3 à 5 projets open source de taille moyenne, publier les données de temps de revue avant et après, puis facturer les tableaux de bord d'équipe et le déploiement à l'échelle de l'organisation
Traduit de l'anglais. Lire l'original