プルリクエストの制限によりノイズがどのように軽減されるか

かつてないほど多くの人がオープンソースに貢献しており、そのほとんどが支援しようとしています。課題は量を維持することです。プルリクエストの作成がかつてないほど簡単になりました。人物のレビューには、これまでと同じくらい時間がかかります。素晴らしい貢献と低品質のノイズが並ぶと、注目に値するものを見つけるのが難しくなります。

そのため、プルリクエストの制限を導入しました。これは、受信するプルリクエストが多すぎる、低品質のノイズが多すぎる、フローを管理する方法が少なすぎる、という最もよく聞かれる問題を具体化しています。

どのように機能するか

プルリクエストの制限は、書き込みアクセス権のないユーザーがリポジトリ内で一度に開くことができるプルリクエストの最大数を設定します。制限に達すると、別のものを開く前に、一方を閉じるかマージする必要があります。 Copilot またはその他の AI エージェントによって開かれたプルリクエストは、制限にカウントされます。信頼できる寄稿者はバイパスリストに登録される場合があり、制限は免除されますが、寄稿者としての完全なアクセスは受けられません。ドラフトのプルリクエストは制限に対してカウントされません。

GitHub にはすでにインタラクション制限がありますが、これは一時的なクールダウンです。これらの新しいプルリクエストの制限は永続的で構成可能であるため、メンテナは不足していると私たちに伝えた制御を提供します。

制限は投稿者の行動も変化させます。誰でも数秒でプルリクエストを開くことができるようになると、洗練された変更とラフなドラフトがキュー内で同じように見えます。ただし、一度にオープンできるプルリクエストが少数である場合、コントリビューターはレビューしたいコントリビューションを選択し、優先順位を付ける必要があります。最初の決定呼び出しはプルリクエストが届く前に行われ、プールが小さいため、優れた作業を認識しやすくなります。

これは、プルリクエストを再レビューするのに役立ちます。緩いプルリクエストを 5 ～ 10 件オープンしている人がいないことがわかれば、それらを確認するのがはるかに簡単になります。今後、これが私たちのバックログの管理に役立ち、人々が取り組んでいることが私たちに必要なものであることを確認するのに役立つことを願っています。

ニコラス・ティンダル、AutoGPT

この機能は非常に優れています。熱心なユーザーがほぼ同一のレビューを必要とする複数のプルリクエストを送信しているため、私たちはしばらくの間 Homebrew で問題を抱えていました。 AI により高速化されました。これにより、外部からの貢献が引き続き可能になり、メンテナーはユーザーを処理できるプルリクエストのレベルに引き上げることにさらに貢献できます。

マイク・マクエイド、自作

OpenClaw ではコミュニティから膨大な量のプルリクエストを受け取っているため、スパムと戦うために独自のボットを作成する必要がありました。 GitHub が、メンテナがこのボリュームを管理するためのすぐに使えるソリューションを開発できたことを非常に嬉しく思います。

ヴィンセント・コック、オープンクロー

建設費が検討費を上回る

エコシステムの変化により、これらの制限は現在特に重要です。 2023 年 1 月、開発者は 1 か月で 2,500 万近くのプルリクエストを GitHub にマージしました。現在、その数は 9,000 万人を超え、約 3.6 倍に増加しています。 GitHub の歴史の中で最も多くの人が公開でビルドを行っています。

ほとんどの寄付は善意から生まれており、たとえ善意のジェスチャーであっても、ボランティアが応答するよりも速く積み重なる可能性があります。 2月に私たちは、オープンソースが永遠の9月を迎えようとしていると書きました。プルリクエストの制限により、次のコントリビューターへの扉を閉ざすことなく、その注意の一部がメンテナーに返されます。

次の予定: 投稿を管理するためのコントロールの追加

プルリクエストの制限は最初のステップにすぎません。これと同じ反応が、その後に起こること、つまり、コントリビューションの流れをより柔軟に、より詳細に制御することを直接示しています。

プルリクエストはアーカイブ中です (近日出荷予定): リポジトリ管理者は、プルリクエストをアーカイブして、低品質またはスパムのプルリクエストをメインのプルリクエストビューから非表示にすることができます。管理者はアーカイブされたプルリクエストに引き続きアクセスできますが、デフォルトのリストからフィルタリングすることができます。私たちは意図的に削除ではなくアーカイブを選択しました。組織によっては、法的またはコンプライアンス上の理由からプルリクエストを完全に削除できない場合があり、多くのメンテナは参照用にプルリクエストを保存したいと考えています。

問題の制限 (開発中): プルリクエストに対する現在の制御は、リポジトリごとの上限、書き込みアクセス権のないユーザーが一度にオープンできる課題の数の制限、バイパスリスト、課題の作成をコラボレーターに制限するオプションなど、課題に適用されます。

より良いバイパス信号 (次):目標は、手動の信頼管理を減らすことです。バイパスリストを手動で作成する代わりに、実際のシグナル (リポジトリに既にマージされているプルリクエスト、アカウントの年齢、または組織のメンバーシップ) に基づいて、コントリビューターが制限を自動的にクリアできるようにすることができます。これにより、メンテナはリストを手作業で準備することから解放され、目の前の仕事に集中できる時間が増えます。

リポジトリ間の制御 (探索): リポジトリごとの上限は、プロジェクト内の反復的なアクティビティには役立ちますが、誰かが一度に何百ものリポジトリにプルリクエストをオープンした場合には何も役に立ちません。私たちは、信頼シグナル、レート制限、その他のリポジトリ間制御を通じて、複数のリポジトリにプルリクエストをスプレーする投稿者を捕まえる方法を模索しています。

ありがとう

オープンソースは毎日現れる人々の上で動いています。夜遅くまでプルリクエストをレビューしたり、初めてのコントリビューターを指導したり、バックログを解決したり、問題を提出したり、ツールが不足している点を私たちに知らせてくれたりする皆さん、ありがとうございます。この機能は皆さんによって形作られました。皆さんの意見は、次に何が起こるかを決定する上で重要です。私たちはあなたと一緒に構築し続けます。

リポジトリ設定でプルリクエストの制限を試して、それが役立つところと役に立たないところをお知らせください。

プルリクエストはキューに入れられます。 🧡