すべての新しい TensorFlow の機能は、Request for Comment (RFC) から始まります。
RFC は、要件とそれを解決するために提案された変更を説明するドキュメントです。具体的には、RFC は以下のようになります。
- RFC テンプレートに従って書式設定します。
- プルリクエストとして community/rfcs ディレクトリに送信します。
- 承認の前に、議論およびレビュー会議の対象となります。
TensorFlow Request for Comments (RFC) の目的は、利害関係者や専門家からフィードバックを得て、設計変更に関する意見を広く交換し、TensorFlow コミュニティを開発に参加させることです。
RFC の提出方法
RFC を提出する前に、プロジェクトの貢献者やメンテナと目的について話し合い、初期のフィードバックをもらいます。関連するプロジェクトの開発者メーリングリスト（developers@tensorflow.org、または関連 SIG のリスト）を使用してください。
RFC を起草します。
- デザインレビューの基準を読みます。
- RFC テンプレートに従います。
- RFC ファイルには
YYYYMMDD-descriptive-name.mdと名前付けします。YYYYMMDDは提出日、descriptive-nameは RFC のタイトルに関連したものにします。（例えば、RFC のタイトルが Parallel Widgets API の場合、ファイル名は20180531-parallel-widgets.mdを使用します。） - 画像やその他の補助ファイルがある場合は、それらのファイルを保存するために
YYYYMMDD-descriptive-name形式のディレクトリを作成します。
RFC 草案を作成後、提出する前にメンテナや貢献者からフィードバックをもらいます。
実装コードの作成は必須ではありませんが、設計に関する議論で役立つ場合があります。
スポンサーを募集します。
- スポンサーはプロジェクトのメンテナでなければなりません。
- プルリクエストを投稿する前に、RFC にスポンサーを明記します。
スポンサーなしで RFC を投稿することは可能ですが、プルリクエストを投稿後 1 か月経過してもスポンサーがつかない場合には、その RFC は閉鎖されます。
RFC をプルリクエストとして tensorflow/community/rfcs に送信します。
Markdown を使用して、プルリクエストのコメントにはヘッダーテーブルと Objective セクションのコンテンツを含めます。例については、この RFC の例をご覧ください。共著者、レビュー担当者、スポンサーの GitHub ハンドルも含めます。
プルリクエストの上部にある、コメント期間の長さを指定します。コメント期間の長さは必ずプルリクエスト投稿日から 2 週間以上にします。
簡単な説明、プルリクエストへのリンク、レビューのリクエストをメールで開発者メーリングリストに送信します。この例にあるように、過去のメールの形式に従います。
スポンサーは RFC のプルリクエストが掲載されてから 2 週間以内にレビュー委員会の会議をリクエストします。議論が活発な場合は、解決するまで待ってからレビューに進みます。レビュー会議の目的はマイナーな問題の解決なので、大きな問題についてはレビュー前に合意に達しておく必要があります。
会議は RFC を承認、拒否、または再検討を前提に変更を要求する場合があります。承認された RFC は community/rfcs にマージし、拒否された RFC はそのプルリクエストをクローズします。
RFC 参加者
RFC プロセスには多くの人々が関与しています。
RFC 作成者 — RFC を作成し、プロセスを通じてそれを支持することを約束する 1 人以上のコミュニティメンバー
RFC スポンサー — RFC のスポンサーであり、RFC のレビュープロセスを導くメンテナ
レビュー委員会 — RFC の承認を推奨する責任を担うメンテナのグループ
コミュニティメンバーなら誰でも、RFC がニーズを満たしているかについてフィードバックを提供し、貢献することができます。
RFC スポンサー
スポンサーは、RFC プロセスの最良の結果を保証する責任を担う、プロジェクトメンテナです。スポンサーの責任には以下が含まれます。
- 提案された設計を支持します。
- 既存の設計およびスタイルの慣習に準拠するように RFC を指導します。
- 生産的な合意に達することができるようにレビュー委員会を導きます。
- レビュー委員会から変更を要求された場合は、変更が行われたことを確認した後、委員会メンバーに承認を求めます。
- RFC が実装に移行する場合 :
- 提案された実装が設計に準拠していることを確認します。
- 実装が確実に成功するように、適切な関係者と調整を行います。
RFC レビュー委員会
レビュー委員会は、承認、拒否、または変更を要求するかどうかを合意に基づき決定します。委員会の責任は以下の通りです。
- パブリックフィードバックの重要項目が説明されていることを確認します。
- 会議のメモをコメントとしてプルリクエストに追加します。
- 決定理由を提供します。
レビュー委員会の構成は、特定のガバナンススタイルおよび各プロジェクトのリーダーシップに応じて変更される場合があります。コア TensorFlow の場合、委員会は関連するドメイン領域の専門知識を持つ TensorFlow プロジェクトへの貢献者によって構成されます。
コミュニティメンバーと RFC プロセス
RFC の目的は、TensorFlow の新しい変更がコミュニティを適切に代表し、その役割を果たすようにすることです。結果に関心がある RFC のレビューに参加することは、コミュニティメンバーの責任です。
特定の RFC に関心のあるコミュニティメンバーは、次のことを行う必要があります。
- 十分な検討時間を与えるために、できるだけ早くフィードバックを提供してください。
- フィードバックを提供する前に、RFC をよくお読みください。
- マナーを守り、建設的なフィードバックをします。
新機能の実装
RFC が承認されると、実装を開始することができます。
新しいコードでの RFC の実装に取り組む場合には、以下のようにします。
- RFC で承認された機能と設計が理解できていることを確認します。作業を始める前には、質問をして、アプローチについて話し合います。
- 新しい機能には、期待どおりに機能することを確認できる新しい単体テストを必ず含めなければなりません。コードを記述する前に、これらのテストを記述しておくことを推奨します。
- TensorFlow コードスタイルガイドに従います。
- 関連する API ドキュメントを追加または更新します。新しいドキュメントの RFC を参照します。
- 貢献しているプロジェクトリポジトリの
CONTRIBUTING.mdファイルに記載されている、他のガイドラインにも従います。 - コードを送信する前に単体テストを実行します。
- RFC スポンサーと協力し合い、新しいコードの導入が成功するようにします。
ハードルを高く保つ
すべての貢献者には奨励し称賛をしていますが、RFC 承認の基準は意図的に高く設定しています。新しい機能は、次のいずれかの段階で拒否または大幅な修正を求められる場合があります。
- 関連するメーリングリストでの設計に関する初期のやり取り。
- スポンサー募集の失敗。
- フィードバック段階での重大な反対意見。
- 設計レビュー段階での合意内容を達成できなかった場合。
- 実装段階での懸念の発生（例えば下位互換性を実現できない、メンテナンスに関する懸念、など）。
このプロセスがうまく機能している場合、RFC は後の段階よりもむしろ早い段階で失敗することが予想されます。承認された RFC は実装のコミットメントを保証するものではなく、提案された RFC 実装が承認されても、引き続き通常のコードレビュープロセスの対象となります。
このプロセスについて質問がある場合は、開発者メーリングリストで質問するか、または tensorflow/community に issue を報告してください。