負荷に苦しむ OSS メンテナー向けの PR 振り分けゲート
低品質な PR や AI で大量生成された PR を、OSS メンテナーのレビュー時間を使う前に採点してフィルタリングする CI ゲートです。
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.
Claude Code や Cursor などのコーディングエージェントにそのまま貼れる概要(英語)です。
賛成の論拠
- EX.1QGIS は、AI による PR の量が人間のレビュー能力を超え、レビュー担当者の信頼を損なうため、AI によるコントリビューションを正式に禁止しています。記事から ↗
- EX.2Plotly のメンテナーは、校正されていない3ページ分の AI 製 Issue や、もっともらしいが内容の弱い PR がレビュー時間を奪っていると述べ、外部からの貢献を諦めたくなる状況を説明しています。コメントを読む ↗
- EX.3あるコメント投稿者は量の非対称性を説明しています。AI によって低品質なコントリビューターは、メンテナーが評価できる速度の100倍の速さでコンテンツを生成でき、その大半は微妙に質が悪いとのことです。コメントを読む ↗
- EX.4ボトルネックはコードを書くことから、変更が意図通りに動くことを検証することへ移っています。これは見知らぬ相手からの PR で最も深刻になります。コメントを読む ↗
LLM による大量のコントリビューションは2025〜26年に表面化した現象です。QGIS などの主要プロジェクトは、レビュー担当者の注意を配分するツールがないため、暫定策として全面禁止を導入しています。メンテナーからは、フィルタリングが安価にできるならコントリビューションを開いたままにしたいという声も公に出ています。
反対の論拠
LLM によるコントリビューションの洪水は新しく、計測もされており、主要プロジェクトを全面禁止に向かわせています。既存の AI レビューツールはコードを見るもので、メンテナー側のコントリビューションポリシーを適用するわけではありません。これは実在するギャップです。ただし OSS メンテナーから収益を得ることは依然として弱点です。
プロジェクトごとに調整されたポリシー・アズ・コードのルールセットと、多数のリポジトリにわたる低品質と本物のコントリビューションのラベル付きデータが蓄積されていきます。プロジェクトのマージパイプラインに組み込まれると、そのワークフローへのロックインが生まれます。
既存の AI レビューツールはコード品質を見ています。プロジェクトが宣言した AI ポリシーを適用し、低品質または検証できない提出物を検出し、人間が時間を使う前に提出者に再現手順、テスト、動画での説明などの証拠を求める、メンテナー側のコントリビューション・ゲートは存在しません。
3ステップで作る
- 1GitHub Action を作り、届いた PR をテストの有無、関連 Issue、再現手順、作成者の履歴、diff と PR サイズの比率、AI 製らしさのヒューリスティクスなどの努力シグナルで採点します。人間がレビューする前に、不足している証拠を自動で要求します
- 2プロジェクトが AI やコントリビューションのポリシーを宣言できる設定ファイル(YAML)を用意し、設定可能なしきい値でゲートがそのポリシーを適用するようにします
- 3中規模の OSS プロジェクト3〜5件で無償の試験導入を行い、レビュー時間の before/after データを公開してから、チーム向けダッシュボードと組織全体への展開に課金します
英語からの翻訳です。 原文を読む