✓ SopravvissutaN. 2 di 3IndieDevTools

Gate di triage delle PR per maintainer open source sovraccarichi

Un gate CI che valuta e filtra le PR a basso sforzo o generate in massa con AI prima che consumino il tempo di revisione dei maintainer 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.

Apri la discussione ↗

Un brief pronto da incollare in Claude Code, Cursor o qualsiasi agente di programmazione (in inglese).

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.1su 10

Argomenti a favore

Chi pagaMaintainer e responsabili ingegneria di progetti open source finanziati e fondazioni (ad esempio progetti come Plotly, realtà di scala QGIS, o uffici OSS aziendali) con budget per infrastruttura o community, disposti a pagare da 200 a 800 dollari al mese per add-on CI.

Cosa ha detto la gente

Parafrasato dalla discussione. Segui i link per i commenti originali.

Perché ora

L'ondata di contributi generati da LLM è un fenomeno del 2025-26: grandi progetti (QGIS ora, altri stanno valutando) stanno introducendo divieti generalizzati come misura provvisoria proprio perché non esistono strumenti per razionare l'attenzione dei revisori, e i maintainer dichiarano pubblicamente che continuerebbero ad accettare contributi esterni se il filtraggio fosse economico.

Argomenti contro

✕ Cosa la farebbe fallireIl rilevamento della paternità AI non è affidabile, quindi il prodotto si riduce a un linter CI sofisticato e i clienti abbandonano appena gli incumbent includono un gate simile gratuitamente in GitHub.

L'obiezione più forte del red team

L'ondata di contributi LLM è nuova, misurata e spinge i grandi progetti verso divieti generalizzati; i reviewer AI esistenti valutano il codice invece di far rispettare una policy di contributo lato maintainer, quindi il gap è reale, anche se monetizzare i maintainer OSS resta l'anello debole.

Fossato 4/10

Set di regole policy-as-code calibrati per progetto e dati etichettati che si accumulano sui pattern di contributi a basso sforzo rispetto a quelli genuini su molti repository; lock-in del flusso di lavoro una volta integrato nella pipeline di merge di un progetto.

Cosa esiste già

CodeRabbitGitHub Copilot code reviewGreptilehuman triage / stale-bot automation

Il vuoto

I reviewer AI esistenti valutano la qualità del codice; nessuno agisce come gate lato maintainer che applica la policy AI dichiarata da un progetto, segnala contributi a basso sforzo o non verificabili e richiede al contributore prove (repro, test, video dimostrativo) prima che venga speso tempo umano.

Costruiscila in 3 passi

1Costruire una GitHub Action che assegna un punteggio alle PR in arrivo su segnali di sforzo (test inclusi, issue collegata, passi di riproduzione, storico dell'autore, rapporto diff/dimensione PR, euristiche di stile AI) e richiede automaticamente le prove mancanti prima della revisione umana
2Distribuire un file di configurazione della policy (YAML) con cui i progetti dichiarano la propria policy su AI e contributi, e il gate la applica con soglie configurabili
3Avviare un pilota gratuito con 3-5 progetti OSS di medie dimensioni, pubblicare dati prima/dopo sul tempo di revisione dei maintainer e poi far pagare dashboard per team e rollout a livello di organizzazione

Discussione originale“QGIS enacts moratorium on AI contributions” ↗377 punti, 405 commentiDalla storiaArticolo collegato

Tradotto dall'inglese. Leggi l'originale

Gate di triage delle PR per maintainer open source sovraccarichi

Argomenti a favore

Argomenti contro

Costruiscila in 3 passi

Altro da questo numero