ブランチの分岐とマージを表す抽象的なグラフと、右上に上限ゲージを模した円形アイコンのイラスト

記事

GitHub、下書きPRも上限カウント対象に——低品質な大量投稿を抑止

GitHubが、リポジトリのプルリクエスト数制限に下書き(Draft)のプルリクエストも含められるよう変更しました。これまで上限を回避する抜け道になっていた問題への対策です。

GitHubは公式changelogで、リポジトリに設定できる「プルリクエスト数の上限」機能について、これまで対象外だった下書き(Draft)状態のプルリクエストも、上限のカウント対象に含められるようにしたと発表しました。メンテナーが低品質な大量投稿に悩まされている実情を受けた変更です。

何が変わったのか

GitHubは「メンテナーは自分のリポジトリで低品質な貢献が増えているのを目にしており、それらをより良く管理する方法を必要としている」と説明し、プルリクエスト数の上限設定に、下書きプルリクエストも含めるオプションを追加したと発表しました。リポジトリ管理者は、書き込み権限を持たないユーザーが同時に開けるプルリクエストの数に上限を設定でき、今回の変更によって、この上限に下書きも計上するかどうかを選べるようになります。

GitHubのリポジトリ設定画面で、プルリクエスト数の上限と下書きプルリクエストの扱いを切り替えるトグルが並んだスクリーンショット

画像引用元: GitHub Blog

これまでの抜け道と、その影響

GitHubの説明によれば、従来は下書きプルリクエストが上限の対象外だったため、ユーザーは他の種類のプルリクエストに上限が設定されていても、下書きであれば際限なく作成できてしまっていました。これは単なる見た目の問題にとどまらず、不要な通知やCI(継続的インテグレーション)の実行が積み重なり、リポジトリ側の負荷やノイズを増やす要因になっていたといいます。今回の変更は、この抜け道を塞ぎ、スパム的な投稿によって発生する雑音や計算資源の消費を抑えることを狙ったものです。

プルリクエスト上限機能そのものについて

プルリクエスト数の上限は、オープンソースプロジェクトのように不特定多数から貢献を受け付けるリポジトリで特に有効な機能です。管理者は上限人数を設定しつつ、信頼できる貢献者を「バイパスリスト」に登録することで、上限の対象から除外できます。近年GitHubは、トリアージ(triage)権限を持つユーザーでもプルリクエストのアーカイブ操作ができるようにするなど、リポジトリ運用を管理者だけに集中させない方向の機能拡充を続けており、今回の変更もその一環と位置づけられます。

毎年10月に開催される「Hacktoberfest」のようなイベント期間中は、ノルマ消化のためだけに内容の薄いプルリクエストを大量に送りつける参加者が問題視されることがあり、人気のオープンソースリポジトリほどこの種の低品質な投稿に悩まされがちです。下書き状態であっても通知やCIの起動といった負荷は実質的に発生するため、これまでは上限を設定していても下書きを連投されると対策になりにくい状況でした。今回の変更は、まさにこうした季節的なスパム的投稿の抜け道を塞ぐ狙いがあると考えられます。

同じ日に公開された関連アップデート

GitHubはこの変更と同じ10月8日付のchangelogで、リポジトリ運用に関わる更新をほかにも公開しています。主なものは次の通りです。

トリアージ権限者によるプルリクエストのアーカイブ: これまではリポジトリ管理者に限られていたプルリクエストのアーカイブ・アーカイブ解除操作を、トリアージ(triage)権限以上のユーザーにも開放。ルーティン作業を管理者だけに集中させない運用がしやすくなります。
スクリーンリーダーでのタイムライン読み上げ改善: issueやプルリクエストのタイムラインを、支援技術がリスト構造・件数・現在位置を伴って読み上げられるように改善。アクセシビリティ面の強化です。

いずれも管理権限の分散や利用者体験の改善という点で、今回の下書きプルリクエスト対応と方向性を共にするアップデートといえます。

メンテナー・開発者への影響

オープンソースのメンテナーにとっては、下書きプルリクエストを使って様子見や作業途中の共有を行う貢献者が一定数いる一方で、同じ仕組みが低品質な投稿の温床にもなり得るというジレンマがありました。今回の設定変更により、プロジェクトの実情に応じて「下書きも含めて制限する」か「従来通り下書きは対象外にする」かを選べるようになったことで、メンテナーは自分たちの運用ポリシーに合わせて柔軟に調整できます。該当の上限設定は、リポジトリの設定画面から確認・変更が可能です。GitHubはこの設定の使い勝手について、Community discussionでのフィードバックを呼びかけています。

普段から大量の下書きプルリクエストを開くワークフローを採用しているチームにとっては、設定を有効にする前に、自分たちの運用が上限に抵触しないかを確認しておく必要があります。逆に、個人開発者からの投稿を主に受け付ける小規模なリポジトリであれば、デフォルトに近い上限のままでも十分に抜け道をふさげるはずです。いずれにしても、プロジェクトの規模や貢献者層に応じて、まずは上限値とバイパスリストの組み合わせを見直すところから始めるのが現実的でしょう。地味な設定変更ではありますが、リポジトリの健全性を保つための選択肢が一つ増えたことは、日々大量のプルリクエストに向き合うメンテナーにとって歓迎すべき知らせといえそうです。