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