.NET リポジトリを含む一部のリポジトリでは、"PR Merger" Webhook が有効になっていないため、小規模な PR が自動的にマージされます。 この記事では、それらのリポジトリに対する PR レビュー プロセスについて説明します。 PR レビュー プロセスは、以下の目標に沿って設計されています。
- 担当チーム、製品チーム メンバー、およびコミュニティ メンバーによる高品質なコンテンツを公開する。
- 一貫した方法で、作成者に適切なタイミングで実施可能なフィードバックを提供する。
- 作成者とレビュー担当者間のディスカッションを容易にする。
プロセスは、チームの改革とプラットフォームの成熟に伴って、継続的に発展します。
レビュー担当者
コンテンツ チーム メンバーの 1 人が、すべての PR をレビューします。 コンテンツ チーム メンバーは、技術的な精度を検証するために、特定の製品チーム メンバーによるレビューを依頼できます。 コンテンツ チーム内では、GitHub のコード所有権の機能を使用して、自動的にコンテンツ チーム メンバーによるレビューを依頼します。 このプロセスの一環として、レビュー担当者は、内部 PR をレビューする他のチーム メンバーをタグ付けできます。 チーム メンバーは、同じキュー内のチーム メンバーおよびコミュニティ メンバーから依頼されたレビューを表示します。
コミュニティ メンバーは、PR を確認し、フィードバックも提供します。 ただし、マージする前に、1 人以上の主要なコンテンツ チームのメンバーが、すべての PR を承認している必要があります。
レビュー プロセス
レビューは、PR に基づく以下の 3 つのパスのいずれかに従います。
- 小規模な PR - 小規模な PR は単一のバグ修正 (入力ミス、壊れたリンク、小規模なコード変更、類似の変更など) です。
- 主要なコントリビューション - 主要なコントリビューションとは、既存の記事、新しい記事に対する重要な編集や、多数の記事に対する編集のことです。
- 進行中の作業 - 作成者は、"ドラフト" の pull request を開くことによって、まだレビューの準備ができていないとマークされている PR を作成できます。
"小規模" と "大規模" なコントリビューション間の区別に関しては、共同作成者使用許諾契約書 (CLA) ボットによって使用される処理の過程が、優れた指標になります。 CLA の署名を必要としない PR は、多くの場合 "小規模" です。CLA を必要とする PR は、多くの場合 "大規模" です。
小規模な PR
小規模な PR での変更は、精度に関してレビューが行われ、校閲サイトのビルドを使用してチェックされます。 小規模なため、これらの PR は記事全体のレビューをトリガーしません。
レビュー担当者は、記事の改善になる軽微な変更点に気付くことができます。 また、変更点が軽微な場合は、レビュー コメントとして提案します。 提案された変更点によって、より大規模なレビューが発生する場合は、課題を開設して、後で対処します。
より重大な変更点
より大規模な PR では、もっと完全なレビューが実施されます。 次の点がすべてチェックされます。
- サンプル コードは必ず、PR 内、ソース内、およびダウンロード可能な zip ファイルとして組み込まれている。
- サンプル コードはコンパイルして、適切に実行される。
- 記事では、読者の目標を明示的に説明し、それらの目標を満たしている。
- 記事がスタイルおよび文法に関するガイドラインを満たし、ボイスとトーンに関する原則に従っている。
- すべてのリンクが正しく解決される。
コンテンツ チーム メンバーは PR をレビューし、コメントを付けてレビューを送信します。 軽微な変更のみが必要な場合、チーム メンバーは、フィードバックで PR を "承認" できます。 作成者は、フィードバックに対処してから、PR をマージできます。 ほとんどのレビューで変更が必要になると、変更が行われた時点で、レビュー担当者が再度レビューします。
編集に技術レビューが必要になった場合、コンテンツ チームのレビュー担当者は、適切な製品チーム メンバーによるレビューを依頼します。
ドラフトの pull request をレビューする
プロセスの早期にフィードバックが必要な場合があります。 ドラフト PR を開き、早期レビューを要求するコメントを追加します。 これらの早期レビューでは、アウトライン、全体のコンテンツ、およびサンプルといった、記事の構成に注目します。 これらのレビューには、文法および適切なリンクに関する完全なチェックは含まれません。
提案の説明
GitHub では、suggestion 型の 3 つのバック ティック ブロックにコメントを入力できます。それは差分として表示され、ボタンをクリックすることでマージできます。 短い行の場合は、GitHub によって変更がうまく強調表示されます。 長い行 (1 行のテキストの長い段落など) の場合は、GitHub によって変更が強調表示されません。 長い行の提案を入力するときに、変更が明確に強調表示されているかどうかを確認します。 変更が強調表示されていない場合は、提案ブロックの外に変更内容を説明するコメントを含めてください。 説明がないと、後続のレビュー担当者や PR 作成者が変更内容を把握するのに時間がかかることがよくあります。
レビューに回答する
作成者は、コメントに応答するように PR を更新します。 作成者がコメントに同意しない場合、または別の PR でそのコメントに対処する場合、作成者は、自分の変更内容を説明するコメントを追加します。
作成者は、コメントで元のレビュー担当者に対して @メンションして、新しいレビューを要求します。
期待される回答期限
コンテンツ チーム メンバーは通常、新しい PR を 2 営業日でレビューします。
レビューが送信されると、その後、作成者は 1 週間以内にコメントに回答するように努力する必要があります。 協力者は、他の作業を理由に、これらの期限に間に合わせられない場合があります。 その場合、チーム メンバーは、コミュニティ作成者に PR を更新するつもりかどうかを尋ねます。 コミュニティ作成者が更新しない場合は、チーム メンバーが、協力者に対する PR を更新してマージします。