CONTRIBUTING.mdでのコードレビューガイドライン
CONTRIBUTING.mdにコードレビューガイドラインを追加。レビュアーの期待、フィードバックのエチケット、承認基準、リクエストされた変更への対応方法をカバー。
Processes
詳細な説明
コードレビューガイドラインの作成
明確なコードレビューの期待は、レビュアーとコントリビューターの両方にメリットがあります。摩擦を減らし、レビュープロセスを加速し、一貫した品質を維持します。
コントリビューター（PR著者）向け
レビューを依頼する前に：
- 自分のPRを自分でまずレビューする
- すべてのCIチェックが通過することを確認する
- 何をそしてなぜを説明する明確なPR説明を書く
- PRを集中させる：PRごとに1つの機能または修正
- UI変更にはスクリーンショットを追加する
レビュー中：
- 確認のためだけであっても、すべてのフィードバックに応答する
- フィードバックが不明確な場合は説明を求める
- フィードバックを個人的に受け取らない -- コードについてです
- レビュー中は新しいコミットとして修正をプッシュする（マージ時にsquash）
レビュアー向け
レビューの優先事項：
- 正確性 -- コードは主張通りに動作するか？
- セキュリティ -- 脆弱性はないか？
- パフォーマンス -- 不要な非効率はないか？
- 可読性 -- 次の開発者がこれを理解できるか？
- スタイル -- プロジェクトの規約に従っているか？
フィードバックのエチケット：
# 良いフィードバック
「キーが動的なユーザーIDなので、O(1)の検索のために
ここではObjectの代わりにMapの使用を検討してください。」
# 悪いフィードバック
「これは間違い。Mapを使って。」
承認基準
- すべてのCIチェックが通過
- 少なくとも1人のメンテナーの承認（破壊的変更には2人）
- 未解決の会話がない
- 動作が変更された場合はドキュメントが更新されている
- テストカバレッジが維持または改善されている
ターンアラウンドタイム
期待を設定：「メンテナーは3営業日以内に初回レビューを提供することを目指します。複雑なPRにはより時間がかかる場合があります。」
停滞したPR
PRが停滞と見なされる時期とその後の対応を定義：「30日間活動のないPRはstaleとマークされます。さらに14日後にクローズされます。いつでも再オープンまたは新しいPRを提出できます。」
ユースケース
コードレビューで摩擦が生じているプロジェクトで、コントリビューターがぶっきらぼうなフィードバックに落胆し、レビュアーが基本基準を満たさないPRに多くの時間を費やしている場合。