GitHubは6月17日、書き込み権限のないユーザーによる同時に開かれているPR数を制限する機能を公開しました。AIが大量に生み出す低品質PRにメンテナーが悩まされているという話の末に出てきた機能であり、2016年から要望されていたものでもあります。
そこで、実際のリポジトリのキューでこれがどれほどふるい落とせるのかを測ってみました。ボットを除き、書き込み権限のない作成者が開いたPRだけを数え、上限を3にした場合に何件が先送りされたかを計算しました。
- huggingface/transformers — オープンPR 55件 / 作成者 49人 / 上限3で先送りされたPR 1件
- typescript-eslint — 28件 / 24人 / 1件
- DIYgod/RSSHub — 26件 / 23人 / 1件
- django/django — 79件 / 59人 / 7件
- caddyserver/caddy — 58件 / 43人 / 7件
- coollabsio/coolify — 86件 / 68人 / 11件
2〜13%です。
理由はキューの形でした。transformersではPR 55件が49人の作成者から来ています。coolifyは86件に68人です。1人が30件開くスパムのパターンではなく、30人が1件ずつ開いているのです。上限は前者を狙って作られましたが、実際のキューは後者です。
この機能が役に立たないという話ではありません。1つのアカウントがキューを埋め尽くすリポジトリは実在し、そうした場所には以前、防御手段がありませんでした。ただ、レビュアーに届く量はほとんど変わらないということであり、何を先に読むかを決める仕事は残ります。
あわせて、もう1つ測ってみたことがあります。低品質PRを自動で閉じるアクションを導入しているリポジトリ167件を調べたところ、キューが生きている30件はすべて pull_request_creation_policy が all でした。デフォルト値なので「誰も変えていない」という意味ではありますが、制限の動機が最も強い集団が、入口は閉じずにフィルターだけを付けていた、とも言えます。
そして、その167件のうち126件（75%）はオープンPRが4件未満でした。「N件のリポジトリがスロップフィルターを入れた」を「N件のリポジトリが洪水を経験している」と読んではいけない、という意味です。私もそう読んでしまい、実際に測ってから考えを改めました。
測定方法と限界はリンク先の文書にあります。上限3は私の仮定であり（リポジトリごとに異なる設定ができます）、オープンなキューのスナップショットなので、上限に阻まれて最初から開かれなかったPRは見えません — それもこの機能の要点の1つではあります。公開PR一覧さえあれば、誰でも再現できます。
（開示：この測定は私が作ったPRトリアージチェッカーから出てきたものです。利害関係があるという意味なので、その点を踏まえて読んでください。数値はリポジトリごとの公開PR一覧からそのまま再現できます。）
まだコメントはありません。