コミット担当者のガイドライン¶

このページは、Ansible GitHub リポジトリー上でコミット権限を持つユーザーのためのガイドラインです。コミット担当者は、基本的に Ansible Core チームのメンバーとして活動していますが、必ずしも Ansible および Red Hat の従業員である必要はあります。コミットする前にこのガイドラインをお読みください。

これらのガイドラインはすべてのユーザーに適用されます。同時に、これはプロセスのドキュメントではありません。したがって、適切な判断をしてください。コミットアクセス権が与えられているのは、そのユーザーの判断を信頼しているためです。

そのため、その信頼については慎重に行動してください。

信頼を乱用してコンポーネントやビルドなどを壊してしまうと、信頼のレベルが下がり、コミットしないように求められたり、コミット権限を失うことになるかもしれません。

機能、高レベル設計、およびロードマップ¶

コミット担当者は、コアチームメンバーとして、ロードマップを作成するチームに不可欠です。積極的に関与し、希望する機能や修正をプッシュしてください。また、Red Hat は企業として、様々なリリースに対して、特定の機能、修正、API などにコミットすることを念頭に置いてください。企業である Red Hat、および Ansible チームは、このようなコミットされた機能 (など) を完成させ、スケジュール通りにリリースしなければなりません。ユーザー、コミュニティー、顧客への義務が最優先されなければなりません。これらの義務があるため、自分で開発したい機能が Ansible 内の他の多くの部分に影響を与える場合は、その機能がリリースに含まれない可能性があります。

その他の新機能や高レベル設計の変更は、コミュニティーおよび Core チームがアイデアを確認して承認する機会を確実にもてるように、提案プロセス (TBD) を経る必要があります。提案に基づいて新機能をマージする責任は Core チームにあります。

GitHub でのワークフロー¶

コミット担当者として、以下をすでに理解しているかもしれませんが、私たちのワークフローは多くのチームポリシーを形成しています。以下のワークフローの手順を理解しておいてください。

作業したいリポジトリーを自身のリポジトリーにフォークします。
コミットする必要がある特定のブランチで作業します。
プル要求を Ansible リポジトリーに作成し、レビューしてほしいユーザーにタグを付けます。そのユーザーを、その要求の主な「所有者」として割り当てます。
提供されたコメントに基づいて必要に応じてコードを調整します。
Core チームに最終確認とマージを依頼します。

コミット担当者のワークフローへの補足¶

Core チームは、これが時に困難なプロセスであることを認識しています。時には、チームが直接コミットしたり、自身のプル要求をマージしたりしてルールを破ってしまうこともあります。ここではガイドラインを示します。ドキュメントでコンマを変更する場合や、ごく些細な変更であれば、各自の裁量で行ってください。これも信頼関係の問題です。大きな変更にはプロセスが重要ですが、ちょっとしたことや迅速に何かを行う場合は、最善の判断を下し、チームの人々に自分の仕事を認識してもらうようにしましょう。

Core におけるロール¶

Core のコミット担当者 - ほとんどの場合は、プル要求を実行しても問題ありませんが、タイムボックスが必要です。解決されていないプル要求が存在すると、開発者の判断でマージされます。
モジュールメンテナー - モジュールメンテナーは特定のモジュールを所有しており、現在のモジュールのプル要求メカニズムを通じて間接的にコミットにアクセスできます。

一般的なルール¶

ansible/ansible への直接コミットアクセスを持つユーザーには、さまざまなことを可能にする権限が与えられています。これは、ルールというよりは、一般的な ガイドライン として扱い、この権限を持つユーザーは最善の判断を下すことが期待されています。

してはいけないこと
- 直接コミットする。
- 自身のプル要求をマージする。他の誰かがプル要求のマージを確認して承認する機会を持つべきです。Core のコミット担当者であれば、ごくわずかな変更であれば、各自の裁量で行うことができます。
- 代替環境のことを考えない。代替案を検討してください。ユーザーの中には環境が良くない人もいますが、私たちを最も必要としているのはそのようなユーザーです。
- コミュニティーチームのメンバーの足を引っ張る。技術的なメリットについては常に議論するべきですが、一個人の限界については決して言及すべきではありません (IRC、GitHub などでは特に注意してください)。
- メンテナンスの負担を考えない。その機能が本当に優れていても、メンテナンスの負担が大きすぎる場合は、組み込む価値がないかもしれません。
- Playbook を壊す。常に下位互換性を念頭に置いてください。
- シンプルにすることを考えない。複雑なものは、あらゆる種類の問題を生み出します。
すべきこと
- squash を使用し、マージはできる限り使用せず、必要に応じて GitHub の Squash コミットを使用するか、入念に選びます (cherry-pick)。
- 活発に行動する。(マージ、トリアージ、コミットなどを通じて) プロジェクトで活動をしていないコミット担当者は、そのパーミッションが停止します。
- 下位互換性を検討してください。
- テストを作成する。テストが含まれているプル要求は、テストが必要なのに含まれていないプル要求よりも優先度が高く見られます。すべての変更がテストを必要とするわけではありませんが、バグ修正や機能変更の際には必ずテストを追加しましょう。
- 特に不明な点がある場合は、他のコミット担当者と話し合ってください。
- 文書化する。プル要求が新機能や動作の変更であれば、関連するすべてのドキュメントを更新したか、適切なユーザーに通知したかを確認してください。また、本ドキュメントと互換性がある Core のバージョンを追加するのに便利です (安定版と開発版のドキュメントとの混同を避けるため、後方互換性のためなど)。
- スコープを検討する。時には修正を一般化できる場合があります。
- 複雑にせず、保守やデバッグが可能で、分かりやすいものにする。

コミット担当者は、その他の Ansible コミュニティーメンバーが従っているコミュニティーおよび貢献に関するガイドラインに従い続けることが期待されています。

ユーザー¶

このグループの一員になることを求められたユーザーは、通常、しばらくの間 Ansible コミュニティーに重要な貢献をしてきたユーザーです。同意したユーザーは、以下のセクションにあるこのファイルに名前と GitHub ID をプル要求で追加してください。この操作は、その他のコミット担当者が信頼できる行動をとることに同意していることを意味します。