より健全な Clippy に向けた共同レビューの提案

• Rust のリンター Clippy はここ数か月、プルリクエストのレビューでボトルネックに直面しており、コントリビューター同士が互いの変更を先に確認する共同レビュー手順を導入
• メンテナンス作業に対して 資金提供を受けている Clippy チームメンバー がいないため、レビューと管理の負担がメンテナーの自由時間に集中し、バーンアウトのリスクが高まっている
• 新しい手順では、コントリビューターがプルリクエストを開くと @rustbot が、まだレビューのない別のプルリクエストを優先的に確認するよう案内する
• 他のコントリビューターのプルリクエストをレビューした人は secret list に載り、その後、自分のプルリクエストがチームのレビュアーから優先的に扱われる
• Clippy チームは Rust Foundation Maintainers Fund とコミュニティの参加が、メンテナーの負担を減らし、プロジェクトの状態を改善する助けになることを期待している

---

Clippy が直面するレビューのボトルネック

• Clippy は、多くのコントリビューターが機能追加やバグ修正をプルリクエストとして提出する Rust のリンタープロジェクト
• ここ数か月、レビュー能力が不足し、プルリクエスト処理にボトルネックが発生している
• 他の一部の Rust チームとは異なり、現在の Clippy チームには Clippy の作業に対して資金を受け取っている人がいない
  • パートタイム基準でも支援を受けている人はいない
  • メンテナンス負担はメンテナーの自由時間にかかっている
  • こうした構造はバーンアウトにつながり得る
• チームは、新設された Rust Foundation Maintainers Fund が Clippy メンテナーの資金確保に役立つことを期待している
  • 貢献したい人は Rust Foundation Sponsors に寄付できる

コントリビューター同士でレビューする手順

• 新しい手順の目的は、コントリビューター同士が助け合い、プルリクエストがより早くレビューされ、マージされるようにすること
• コントリビューターがプルリクエストを開くと、他のコントリビューターのプルリクエストを先に確認する流れで進む
  • 各コントリビューターは少なくとも1件のプルリクエストをレビューする
  • 他の人の貢献が長く放置されないようにするための仕組み
• @rustbot は、新しいプルリクエストの作成者に、他のプルリクエストを確認するよう案内する
  • 可能であれば、まだレビューが付いていないプルリクエストが優先対象となる
• レビューを終えたコントリビューターは、特別な secret list に載る
  • その後、自分のプルリクエストはチームのレビュアーから優先的に扱われる
• この方式は、Bevy プロジェクトの Open Code Review システムに着想を得ている
• Clippy は以前にも、プロジェクトの健全性を改善するためのアップデートを実施したことがある
  • 2025年の Feature Freeze は成功した
  • その過程でチームは、知識、信頼、そして Rust コミュニティが Clippy と正しい作業方法に関心を持っているという確信を得た
• Clippy チームは、コミュニティの助けによって Clippy がより強く健全になれると見ている

[GN⁺]

Lobste.rs のコメント

• 正直、今回の発表よりも、記事内でリンクされていた Bevy の公開レビュープロセスのほうが興味深かった。以前にここにも投稿されていたが、あまり議論されなかった記事で、本当に思慮深く賢いアプローチだと思う。
  うまく機能していると聞いてうれしいし、驚きはしない。Clippy でも同じような結果が得られるといい。

  • その記事を投稿したのは自分だった。以前は Bevy ゲームエンジンにかなり活発に貢献していて、レビュープロセスもかなり気に入っていた。
    この仕組みは、小さく段階的な PR を促す。誰でも、初めてのコントリビューターでさえ、ずっとレビューしやすくなるからだ。大きな PR はマージまでずっと時間がかかったし、それで正しいと思う。レビューが難しく、コードへのある程度の理解が必要だからだ。たいてい、大きな機能がたくさん入った PR は、メンテナーやその分野の専門家が最後まで押し進めていた。
    その記事がよかったなら、同じ著者による Bevy のメンテナンスに関する記事、Triage-by-controversy and community review と The Tyranny of Nits も気に入るかもしれない。
  • Bevy に貢献したことはないが、彼らのワーキンググループ構造は、導入後に良い結果を出しているように見える。

• 自分が貢献しているオープンソースプロジェクトで PR レビューをあまり手伝わない理由の一つは、専門性がほとんどなく、自分にその資格があるのか確信が持てないからだ。
  Clippy と Bevy のプロセスは、経験の浅いレビュアーでも正当に参加できるようにしていて、かなり良いやり方だと思う。

• タイトルだけを見たときは、期待していたものとは少し違った。

  • そう。記事だけでは、Clippy が実際に何なのかがはっきりしない。調べてみたら Rust のリンターだった。

• アカウントをいくつか作って、複数アカウントで PR を提出すれば簡単に悪用できそうに見える。
  それで何が得られるのかはよく分からないが、優れたコントリビューターの秘密リストに載ること自体が誘因になり得る。

  • この方式に着想を与えた Bevy のレビュープロセスでは、レビュー交換がごく一般的だ。自分と別のコントリビューターが互いのプルリクエストをレビューし、その結果どちらもより早くマージされる。
    コントリビューター同士が同じプロジェクトで作業しているときに最もうまく回っていたが、関係のない作業でもこうしたやり方を見たことがある。Clippy でも同様の慣行が生まれるといい。レビュー交換は作業をより早くマージできるようにし、協力的なコミュニティを育てる。
    ただし、このブログ記事でレビューの仕組みを紹介している段落は改善できる。現状では「別の PR をざっと眺めれば、あなたの PR をより早くマージしてあげる」と読めてしまうが、意図したメッセージはそうではないはずだ。代わりに、他の協力者と一緒に作業することに焦点を当てるべきだ。人々に Clippy の Zulip チャンネルへ行ってレビュー交換を提案してもらい、同じプロジェクトで一緒に作業してもらえば、システムの悪用を促さずに、より健全なコミュニティを作れる。
  • 似たようなことを考えた。不公正な参加者はサブアカウントで偽の機能を作り、本アカウントの実際の作業に本物のメンテナーの関心を引き寄せることができる。
    どちらも次の方法でかなり簡単に避けられそうだ。レビュー相手をランダムに決めて、同じ人の作業を何度もレビューしないようにし、最終的にマージされた PR に対するレビューだけを集計すればよい。

• 他の人の PR や Issue レビューを手助けするサービスとして https://www.CodeTriage.com を運営している。