プルリクエストのレビューを受ける¶

プルリクエストが送信され、CIを通過しました。レビューの準備が整っています。

tl;dr - レビュープロセス¶

レビュープロセスの簡略版：

審査をお待ちください。
フィードバックに対応する。
変更が要求された場合：
要求された変更を完了するまで作業を続ける。
要求されたすべての変更を提出してください。
すべての変更依頼が提出されたら、再審査を依頼してください。
変更が必要なくなるまで、セクション3を繰り返してください。
プルリクエストが承認されマージされるまでお待ちください。

おめでとうございます！BeeWareへの寄付が完了しました！

プルリクエストを送信しました。次に何をすればいいですか？¶

プルリクエストを送信した後、貢献内容のレビューを待つ必要があります。レビュープロセスには二つの側面があります：レビューを提供することと、レビューを受けることです。

期待値の見直し

提出物を審査する者は、コアチームのメンバーによる審査も含め、これらのガイドラインに従うものと期待すべきです。また、他者の提出物を審査する際にも、これらのガイドラインに従う必要があります。

レビュアーがこれらの期待から外れていると感じ、プルリクエスト上で自ら問題提起することに抵抗がない場合は、そうしてください。もしご自身で指摘するのが難しい場合は、BeeWare行動規範対応チームまでご連絡ください。報告内容を精査した上で、該当レビュアーにフォローアップを行います。フォローアップの内容は報告された行為に応じて異なります。軽微な違反の場合は話し合いとなる一方、重大な違反の場合はより厳しい措置が取られる可能性があります。

レビューを提供すること¶

プルリクエストへのレビューはどなたでも歓迎します。これらのガイドラインは、レビューがコアチームメンバーによるものかコミュニティメンバーによるものかを問わず、レビューに求める内容を定めています。

中核メンバーによる最終レビューは常に必要となりますが、コミュニティメンバーによるレビューはプロセスを効率化する有益な手段となり得ます。理想的には、コミュニティレビューで主要な問題点が全て特定された後、中核チームによるレビューは形式的なものとなるでしょう。

レビューを受け取る¶

レビューを受け取るには、以下の3つの基本ステップがあります：

初期のフィードバックと質問。
変更要求
承認とマージ。

各手順の詳細は下記の通りです。プロセス中に質問がある場合は、遠慮なくお尋ねください！喜んでお手伝いいたします。

タイムラインと初期フィードバック¶

コアチームは、すべてのプルリクエストが10営業日以内にレビューされることを目指しています。ただし、より複雑な提出物や、チームの一部が休暇中の際にプルリクエストが提出された場合、このタイムラインが延長される可能性があります。

プルリクエストごとに通常はレビュアーを継続的に担当させます。つまり、レビュー全体を通じて同じレビュアーと協力することになるでしょう。これにより、レビュアーはプロセス全体を通じて状況を把握でき、あなたはレスポンスの頻度やレビューのスタイルについて何を期待できるかを学べます。もし最初のレビュアーが、プルリクエストをレビューするのに必要な専門知識を持っていないと判断した場合、または何らかの理由で対応できないことが分かっている場合、そのプルリクエストの責任を別のチームメンバーに引き継ぐことがあります。

各やり取りに対して、10営業日以内の対応を心がけております。フィードバックや質問への対応は、審査プロセスにおいて不可欠な要素です。次のステップへ進む前に、必ずご返答をお願いいたします。

変更要求¶

ほとんどの場合、レビュアーはプルリクエストに対して変更を要求します。これは必ずしもあなたの仕事の質を反映しているわけではなく、単なるプロセスの一部です。

初期レビューで多数の問題が判明した場合、最初のレビューは包括的ではない可能性があります。代わりに、プルリクエストをマージ可能な状態にするために必要な作業について、高水準な方向性を示すことに重点が置かれます。レビュープロセスでは、試みられた作業の目的と範囲を明確にするための質問が含まれる場合があります。

要求された変更を処理する¶

レビュアーはプルリクエストにコメントを投稿します。これらのコメントは、全体的なもの、特定のファイルに関するもの、あるいは特定のコード行に関するものがあります。時には、GitHub UIを通じてプルリクエストに適用できる直接的な変更提案が含まれることもあります。通常は、質問、説明の要求、または更新に関するガイダンスとなります。

会話を解決済みとしてマークする

フィードバックプロセスの議論段階では、レビュアーが開始した会話を「解決済み」とマークしてはいけません。会話を解決済みとマークするのはレビュアーの責任です。特定された問題が解決されたかどうかを判断するのはレビュアー次第です。

レビューで体系的な問題（例：コード内に存在する命名規則の不一致）が判明した場合、レビュアーはその問題の全事例を指摘しない場合があります。代わりに、問題の事例をいくつか選択し、他の事例も修正すべきであることを示すことがあります。レビューで1箇所の問題が指摘され、それが他の箇所にも適用される可能性があると思われる場合は、問題が発生している箇所をすべて修正してください。不明な点がある場合は、レビュアーに確認を求めてください。

要求されたすべての変更を提出してください¶

要求された変更をすべて反映したら、プルリクエストに更新をプッシュできます。これにより新しいCI実行がトリガーされます。CIが引き続き通過していることを確認したら、更新されたレビューを依頼するコメントを投稿してください。コアチームが再度プルリクエストを確認します。

プッシュはするが、強制したりリベースしたりしない

プルリクエストのレビュー中に更新を行う際は、コミット履歴をそのまま残すことが重要です。コミットの数が膨大であっても問題ありません。プルリクエストをマージする際にすべてスクイーズされます。レビューの途中でプルリクエストを強制プッシュしたりリベースしたりすると、レビュアーが必要とする重要なコンテキストが失われる可能性があります。

再審査を依頼する¶

特定のレビューで要求された変更をすべて解決し、CIが再び通過したら、レビュアーに再レビューを依頼できます。問題が特に複雑で、ある修正が別の箇所に影響を与える場合、更新した特定の部分についてレビューを依頼できます。レビュー依頼は常に完全なレビューを意味するとみなされます。完全なレビューの準備が整っていない場合は、具体的に何を確認してほしいのかを必ず明記してください。

プルリクエストの承認とマージ¶

すべての変更リクエストへの対応が完了すると、プルリクエストは承認されます。ほとんどの場合、プルリクエストが承認されると、直ちにマージされます。ただし、他の未マージのプルリクエストに依存しているなど、やむを得ない事情により遅延が生じる場合があります。その際はコメント欄で状況を説明しますので、ご確認いただけます。