メンテナーとして、プルリクエストのレビューは日常的に行う作業です。
このドキュメントには、Exercism独自のプルリクエストレビューに関するガイドラインをまとめています。
演習のプルリクエストをレビューする
コンセプト演習やプラクティス演習のプルリクエストをレビューするのは、この種の演習に多くのルールがあるため、気が遠くなるような作業になりがちです。
そのため、メンテナーによる最初のレビューには2時間から3時間かかり、何十件ものコメントが付くことも珍しくありません。
コンセプト演習には、目的や内容が似たファイル（演習の紹介文と概念の紹介文など）もあり、あちこちに手を広げる前に、まずどちらか一方を完璧にすることが欠かせません。
この流れを効率よく進められるよう、次のようなおすすめをまとめました。
おすすめ：最初のレビューはシニアメンテナー1人が担当する
最初のレビューをシニアメンテナー1人だけが担当するのには、次のような理由があります。
- レビューの作業が重複しない
- コントリビューターとメンテナーがペアになってプルリクエストに取り組むので、一人でやっているわけではないとコントリビューターに感じてもらいやすい
- 他のメンテナーから矛盾するレビューコメントが付かない
おすすめ：wipステータスでマージする
コントリビューターとメンテナーの双方が演習に納得したら、statusをwip（作業中）に設定してマージします。
このステータスの演習は学習者は利用できませんが、トップメンターは閲覧できるようになります（これは将来いつか実装してからの話です）。
評価の高いユーザーが演習を試し、修正や改善のためにイシューやプルリクエストを作成できるようになります。
このやり方の主な利点は次のとおりです。
- 最初のコントリビューターとメンテナーのペアがすべてを完璧にしなければならない負担を取り除ける
- 多くの人が口を出す巨大なプルリクエストのやり取り（管理がとても大変です）につながらない
プラクティス演習のプルリクエストをレビューする
おすすめ：その変更が本当にproblems-specificationsに属するか考える
プラクティス演習の内容の一部（紹介文など）は、problems-specificationsリポジトリで定義されている（共通の）メタデータから来ています。
そうした内容を変更するプルリクエストをレビューするときは、その変更が他のトラックにも役立つかどうか考えてみましょう。
役立つようであれば、コントリビューターにproblems-specificationsリポジトリの該当ファイルへプルリクエストを出すよう提案しましょう。
レビュー全般のおすすめ
おすすめ：プルリクエストごとに主担当レビュアーを1人決める
すべてのプルリクエストには、主担当レビュアーを1人置きます（引き受けたメンテナーが担当します）。
他のメンテナーやコミュニティのメンバーは、補助的な役割を担います。
補助的な役割の人がレビューに協力できる主な方法は2つあります。
- スペルや文法の校正をする。ただし、_主担当レビュアーによる最初のレビューが終わってから_にしましょう。
スペルや文法の指摘を受けて修正したあとに、別のメンテナーがやって来てより根本的な変更を求められると、コントリビューターはがっかりしてしまいます。
つまり、校正は根本的な変更が片付いた_あと_に行うものです（後続のプルリクエストで行うこともあります）。
- 気づいた点を、_レビュアーにそのまま対応を求めない形で_伝えます。
主担当レビュアーに考えてほしいことや見落としているかもしれないことについてコメントするときは、意見として述べるか、質問の形で書き込んでください。
そうすれば、変更を求めているわけではないことがコントリビューターにはっきり伝わり、混乱も減ります。
主担当レビュアーが「ないがしろにされた」と感じる可能性も減らせます。
おすすめ：関係のないことにはコメントしない
プルリクエストをレビューするときは、そのプルリクエストに直接関係すること_だけ_にコメントします。
それ以外のことは、イシューを立てるか、別の（後続の）プルリクエストを作成してください。
おすすめ：ドキュメントへのリンクを貼る
可能なかぎり、ある点についてコメントする_理由_を説明しているドキュメントへのリンクを貼りましょう。
こうすると、議論が言い争いに発展する可能性を大きく減らせます。
おすすめ：他のチームに助けを求める
プルリクエストのレビューの手伝いを頼みたいときは、声をかけられる専用のチームが2つあります。
-
@exercism/reviewers：一般的なレビュー全般
-
@exercism/github-actions：GitHub Actionsに関する質問
