このページでは、コントリビューターが Bazel コードベースを提案し、変更を加える方法について説明します。
- Bazel コントリビューション ポリシーを確認します。
- GitHub の問題を作成して、計画と設計について話し合う。動作を変更または追加する pull リクエストには、対応する問題をトラッキングする必要があります。
- 大幅な変更を提案する場合は、設計ドキュメントを作成します。
- コントリビューター ライセンス契約に署名していることを確認します。
- 機能を実装する git commit を準備します。必ずテストを追加し ドキュメントを更新してくださいユーザーに見える影響が生じる変更の場合は、リリースノートを追加してください。互換性のない変更については、互換性を破る変更のロールアウトに関するガイドをご覧ください。
- GitHub で pull リクエストを作成する。GitHub を初めて使用する場合は、pull リクエストについてをご覧ください。メインの Bazel リポジトリでブランチを作成する権限は制限されているため、リポジトリの独自のフォークに commit を push する必要があります。
- Bazel の管理者は、2 営業日以内（米国とドイツの祝日を除く）にレビュー担当者を割り当てる必要があります。その時点で審査担当者が割り当てられない場合は、bazel-dev@googlegroups.com にメールを送信して審査担当者をリクエストできます。
- レビュー担当者と協力してコードレビューを実施します。変更ごとに新しい commit を作成して push し、pull リクエストに変更を加えます。審査に時間がかかりすぎる場合（審査担当者から返信がない場合など）は、bazel-dev@googlegroups.com にメールを送信します。
審査が完了すると、Bazel の管理者が Google の内部バージョン管理システムにパッチを適用します。
これにより、内部の presubmit チェックがトリガーされ、さらなる変更を提案する場合があります。ユーザーが設定を指定していない場合、メンテナンス担当者が変更を送信すると、設計に影響を与えない「些細な」変更（lint チェックなど）が追加されます。より深い変更が必要な場合や、変更を直接適用したい場合は、審査担当者と審査担当者がレビュー コメントで希望を明確に伝える必要があります。
内部送信後、パッチは Git commit としてエクスポートされ、その時点で GitHub の pull リクエストが終了します。最終的な変更はすべて、ユーザーに帰属します。