目標
審査プロセスにはいくつかの目標があります。
- 機能と読みやすさの両面でコードの質を高める。
- バグを捕捉しましょう。バグは発生します。
- コードベースの任意の部分で作業を簡単に開始できるように、一貫したスタイルを維持します。
blockly-samples とコア Blockly に含まれるコードはすべて、コミュニティ コントリビューターによる作成か Blockly チームメンバーによるものかにかかわらず、審査を受けます。
審査担当者として、できる限りご希望に沿えるよう審査しております。コントリビューターの方は、Google との会話を通じて pull リクエストを審査し、統合してください。
プロセス
PR の審査プロセスはいくつかの段階を経ます。
職務
pull リクエストを受信すると、Blockly チームのオンコール メンバーがレビュー担当者を割り当てます。
審査担当者は専門知識に基づいて、ワークロードを均等に分散するために選ばれます。
審査担当者が割り当てられるまで数日かかり、審査が完了するまでにさらに数日かかることがあります。心配はいりません。これは正常な動作です。
フィードバック
フィードバックの段階で、審査担当者は PR に変更の提案を残します。これらは簡単な手順で、コードを Google JavaScript スタイルガイドに準拠させるための簡単な作業でもかまいません。あるいは、関数の定義を再編成するよう要求するなど、より規模の大きなものになることもあります。
レビュー担当者には、個々のコメントを入力するのではなく、GitHub のコードレビューを使用して、複数の通知ではなく 1 つの通知を受け取ることをおすすめします。
ディスカッション
ディスカッション フェーズは、フィードバックに返信する機会です。レビュー コメントが明確ではなかった可能性があります。ここで説明を求める機会があります。あるいは、レビュアーが変更をリクエストしたものの、結果に影響が出ると思われる場合、今こそ妥協点を見つけるチャンスです。
リビジョン
リビジョン フェーズでは、PR を変更します。通常、これらの変更は、レビュー担当者がフィードバック フェーズで述べた結果に基づいています。
修正が完了したら、レビュアーにタグを付けて、もう一度見直すよう依頼することをおすすめします。
繰り返し
リビジョン フェーズが終了すると、レビュー担当者は再度フィードバックを提供することができます。プロセスは最初から開始されます。
多くの場合、2 回目の審査はシンプルで、句読点やコードスタイルなどのニトに重点を置いています。時には 2 回目の審査がかなり大きくなることもあります。初めてのクチコミ投稿者は、別の人に見てもらって新しい視点を得ることもできます。
統合！
統合の段階では、それを祝福するチャンスです。変更を作成し、議論と修正を経て、最終的に統合されました。未達成の大きな成果であることはよくありますが、
Blockly の改善にご協力いただき、ありがとうございます。おめでとうございます！