メインコンテンツへスキップ

プルリクエスト

このドキュメントは、プルリクエストをどのようにレビューするかについてのガイドです。

PRをレビューする際は、最善の判断を下してください。そして何よりも、ユーザーに返信する際は、**親切、友好的、励みになる**ことを忘れないでください。多くのユーザーは、オープンソースや型付きLintの初心者です。私たちは彼らにポジティブで、活気づけるような経験を与えることが不可欠です。

ヒント

PRレビューのどの部分でも確信が持てない場合は、より多くのコンテキストを持っているメンテナーに遠慮なく相談してください！

ガバナンス​

貢献者の段階 > ポインティングの段階に従って

  • 単純：レビュー担当者の裁量により、コミッターまたはメンテナーのいずれか1人の承認でマージされる場合があります。これには、ドキュメントの機能強化、バグ修正、機能追加が含まれます。
  • 単純でない：2人のコミッターの承認または1人のメンテナーの承認のいずれかでマージされる場合があります。これらには、マルチパッケージの内部リファクタリングおよび非破壊的なパブリックAPIの変更が含まれます。
  • 「異例」に分類：2人のメンテナーの承認が必要です。これらには、プロジェクト全体およびパブリックAPIへの影響を伴う重要なリファクタリングが含まれます。

PRレビューフロー​

注

私たちは、.github/replies.ymlにPRに対する一般的なレスポンスのセットを含めています。これは、Refined Saved Replies拡張機能で使用することを目的としています。これらを必ず使用する必要がある正確なレスポンスとして扱わないでください。これらは単なるコピー＆ペーストのヘルパーです。単純でないPRの場合は、特定のレスポンスを個人のトーンに合わせ、スレッドに合わせてください。

オープンなプルリクエストは、理想的には2つの状態を切り替えます。

レビューを投稿するたびに、PRにawaiting responseラベルを追加します。作成者がレビューを再リクエストした場合、ラベルは自動的に削除されます。

親切に​

何よりもまず、トーンを励まし、友好的にしてください。

  • フィードバックを、非難するのではなく、改善の機会として表現します。
  • 特に大きなプルリクエストでは、良い点があればそれを指摘します。
  • 楽しい絵文字を頻繁に使用します。
  • もしエネルギーがあれば、レビューと一緒に楽しい（ただし不適切なものではない）GIFを投稿してください。

プルリクエストは、多くのコミュニティメンバーが私たちと、あるいは多くの場合、オープンソースメンテナーと初めて意味のあるやり取りをするときです。ポジティブで、活気づけるような経験を提供することが重要です。❤️

PRのレビュー​

プルリクエストをレビューする前に、サポートしているイシューを振り返り、（再）確認してください。

  • 提供された縮小を単純化してみる（「コードゴルフ」）
  • 同じコード領域/Lintルールに関する以前のイシューとPRを振り返る

サポートしているイシューがない場合

  • PRが、ユーザーに影響を与えない単純なドキュメントやツール修正である場合は、そのままレビューしても問題ありません。
  • それ以外の場合は、please fill out the templateラベルを追加し、Needs Issueテンプレートのようなコメントを投稿してください。

レビューが完了したら、ビルドが成功し、マージしても問題ないと判断した場合は、そのままスカッシュマージしてください。それ以外の場合は、1 approvalラベルを追加してください。

確認する一般的なこと​

  • スタイル：コードを簡単に読み進められるか、必要な難しい箇所にはコメントがあるか、それ以外は不要なコメントがないか。
    • 重要でないことをつまらないことで批判しないようにしてください。
    • リポジトリで標準だが強制されていないものがある場合は、非ブロックコメントとして言及し、それを強制するイシューを提出することを検討してください。
  • 網羅性：関連するエッジケースを処理しているか？一般的に
    • ジェネリクスと型パラメータ（getConstrainedTypeAtLocationを参照）。
    • 括弧と空白（getWrappingFixerを参照）。
    • ユニオンとインターセクション（unionTypePartsとintersectionTypePartsを参照）。
  • 単体テスト
    • Codecov / yarn jest path/to/impacted/file --coverageレポートごとにすべての行がカバーされています。
    • テストすることが合理的に可能な場合、「ポジティブ」ケースと「ネガティブ」ケース（「有効」ケースと「無効」ケース）の両方が存在します。
    • 修正と提案がある場合、//または/*コメントを削除しない
    • invalidLintルールエラーには、行と列の情報が含まれています
    • 有効な構文エッジケースは、TypeScriptで型エラーが発生した場合でも、ルールをクラッシュさせません。

個々のコメント​

賞賛のコメント、提案された変更、またはアクション不可のコメントごとに1つのコメントを投稿します。「（ここにも）」の注釈を示すために複数の補助的なコメントを使用してもかまいませんが、リクエストで圧倒しないでください。

ヒント

複数の種類のコメントを投稿する場合は、[ドキュメント]、[賞賛]、[テスト]などのカテゴリインジケーターをプレフィックスとして検討してください。これは、レビューが大きなリクエストの大きな苦労のように感じられるのを防ぐのに役立ちます。

コメントごとに、何を探しているのか、または何を言っているのかを明確にしてください。必要と思われる以上の情報を提供するようにしてください。

明確なバグではないポイントについては、質問調のトーンをデフォルトにしてください。著者があなたの提案を考えるように促してください。「(xyz)だと思いますが、確信がありません。どう思いますか？」。

予備または繰り返しレビュー​

予備レビューを投稿したり、以前のレビューで見落としたことに後から気づくことがあります。どちらも合理的で問題ありません。

予備レビューの場合は、レビューしている尺度を明確にしてください。「今はアーキテクチャについてレビューしており、それが落ち着いたら詳細を確認します」。

繰り返しレビューの場合は、以前に見落としたこと、または新しい情報がある場合は、明確にしてください。リクエストされた変更が原因で初めて情報が明らかになったとしても、見落としたことを謝罪する必要はありません。これはレビュープロセスの一部です！

その他の状態​

外部ブロッカー​

PRが外部APIやイシューでの議論などによってブロックされている場合は、適切なblocked by *ラベルを追加します。ブロッカーの追跡イシューに少なくともリンクするコメントで理由を説明します。

帯域外の質問​

作成者は、PRに関するコメントとして、@タグを含めて質問をすることがあります。質問に回答する場合は、awaiting responseラベルを戻してください。これらの質問を見落としても心配しないでください。awaiting responseラベルが必要に応じて削除されていることを確認するために、正式な再リクエストレビューを優先します。

古いPRの整理​

時々、私たちはawaiting responseラベルの付いたオープンなPRを検索して、見落とされているかもしれないものを見つけたいと思っています。1ヶ月以上待たされているPRに対する私たちのフローは以下の通りです。

  1. 確認テンプレートのようなメッセージで著者にpingを送る
  2. PRにstaleラベルを追加する
  3. 2週間待つ
  4. それでも応答がない場合は、古いPRの整理テンプレートのようなメッセージでPRをクローズする

PRの検索​

PRに関するその他のクエリには、以下のようなものがあります。

もし時間があれば、時々古いPRを見直して、何週間も未回答の質問がないか確認することを検討してください。