Google is committed to advancing racial equity for Black communities. See how.
このページは Cloud Translation API によって翻訳されました。
Switch to English

TensorFlow RFCプロセス

すべての新しいTensorFlow機能は、Request for Comment(RFC)として始まります。

RFCは、要件とそれを解決する提案された変更を説明するドキュメントです。具体的には、RFCは次のことを行います。

  • RFCテンプレートに従ってフォーマットされている。
  • プルリクエストとしてcommunity / rfcsディレクトリに送信されます。
  • 受け入れる前に、ディスカッションと再検討会議の対象となる。

TensorFlow Request for Comments(RFC)の目的は、利害関係者や専門家からフィードバックを得て、設計変更を広く伝達することにより、TensorFlowコミュニティを開発に参加させることです。

RFCを提出する方法

  1. RFCを送信する前に、プロジェクトの貢献者や保守担当者と目的を話し合い、早期のフィードバックを入手してください。関連するプロジェクトの開発者メーリングリスト(developers@tensorflow.org、または関連するSIGのリスト)を使用してください。

  2. RFCを起草します。

    • RFCテンプレートに従ってください。
    • RFCファイルにYYYYMMDD-descriptive-name.md名前を付けますYYYYMMDDYYYYMMDD-descriptive-name.md日で、 descriptive-nameはRFCのタイトルに関連しています。 (たとえば、RFCのタイトルがParallel Widgets APIの場合、ファイル名20180531-parallel-widgets.md使用できます。
    • 画像やその他の補助ファイルがある場合は、それらのファイルを保存するYYYYMMDD-descriptive-name形式のディレクトリを作成します。

    RFCドラフトを作成した後、提出する前にメンテナや貢献者からフィードバックを入手してください。

    実装コードの作成は必須ではありませんが、設計の議論に役立つ場合があります。

  3. スポンサーを募集します。

    • スポンサーはプロジェクトのメンテナーでなければなりません。
    • PRを投稿する前に、RFCでスポンサーを特定します。

    スポンサーなしでRFCを投稿することはできます 、PRを投稿してから1か月以内にスポンサーがまだいない場合は、RFCは閉鎖されます。

  4. RFCをプルリクエストとしてtensorflow / community / rfcsに送信します。

    Markdownを使用して、プルリクエストのコメントにヘッダーテーブルとObjectiveセクションのコンテンツを含めます。例については、 このRFCの例を参照しください。共著者、レビュー担当者、スポンサーのGitHubハンドルを含めます。

    PRの上部で、コメント期間の長さを特定します。これは、PRの投稿から最低2週間である必要があります。

  5. 開発者のメーリングリストに簡単な説明、PRへのリンク、レビューのリクエストをメールで送信します。 この例でわかるように、以前のメーリングの形式に従ってください。

  6. スポンサーは、RFC PRが掲載されてから2週間以内に、検討委員会の会議を要求します。議論が活発である場合は、レビューが完了する前に、それが解決するまで待ちます。レビュー会議の目的は、軽微な問題を解決することです。事前に主要な問題について合意に達する必要があります。

  7. 会議は、RFCを承認、拒否、または再検討する前に変更を要求する場合があります。承認されたRFCはcommunity / rfcsにマージされ、拒否されたRFCはそのPRをクローズします。

RFC参加者

多くの人々がRFCプロセスに関与しています。

  • RFC作成者RFCを作成し、プロセスを通じてそれを擁護することを約束する1人以上のコミュニティメンバー

  • RFCスポンサーRFCを後援し、RFCレビュープロセスを通じてそれを導くメンテナー

  • レビュー委員会 — RFCの採用を推奨する責任を持つメンテナのグループ

  • コミュニティのメンバーなら誰でも、RFCが彼らのニーズを満たすかどうかについてフィードバックを提供することで助けになるでしょう。

RFCスポンサー

スポンサーは、RFCプロセスの最良の結果を保証する責任を負うプロジェクトメンテナーです。これも:

  • 提案された設計を支持する。
  • 既存の設計およびスタイルの規則に準拠するようにRFCを指導する。
  • 生産的なコンセンサスに来るように検討委員会を導きます。
  • レビュー委員会から変更が要求された場合は、変更が行われたことを確認し、委員会メンバーからのその後の承認を求めます。
  • RFCが実装に移行した場合:
    • 提案された実装が設計に準拠していることを確認します。
    • 適切な関係者と調整して、着陸を成功させる。

RFCレビュー委員会

レビュー委員会は、変更を承認、拒否、または要求するかどうかをコンセンサスに基づいて決定します。彼らは責任があります:

  • パブリックフィードバックの実質的な項目が説明されていることを確認します。
  • 会議メモをコメントとしてPRに追加します。
  • 彼らの決定の理由を提供します。

レビュー委員会の構成は、各プロジェクトの特定のガバナンススタイルおよびリーダーシップに応じて変更される場合があります。コアTensorFlowの場合、委員会は、関係するドメイン領域の専門知識を持つTensorFlowプロジェクトへの貢献者で構成されます。

コミュニティメンバーとRFCプロセス

RFCの目的は、コミュニティがTensorFlowの新しい変更によって適切に表現され、提供されるようにすることです。結果に関心があるRFCのレビューに参加することは、コミュニティメンバーの責任です。

RFCに関心のあるコミュニティメンバーは、次のことを行う必要があります。

  • 検討に十分な時間を与えるために、できるだけ早くフィードバック提供してください。
  • フィードバックを提供する前に、 RFCをよくお読みください
  • 市民的で建設的なこと

新機能の実装

RFCが承認されると、実装を開始できます。

RFCを実装するための新しいコードに取り組んでいる場合:

  • RFCで承認された機能と設計を理解していることを確認してください。作業を始める前に、質問をし、アプローチについて話し合ってください。
  • 新しい機能には、機能が期待どおりに機能することを確認する新しい単体テストを含める必要があります。コードを記述する前に、これらのテストを記述することをお勧めします。
  • TensorFlowコードスタイルガイドに従う
  • 関連するAPIドキュメントを追加または更新します。新しいドキュメントでRFCを参照してください。
  • 貢献しているプロジェクトリポジトリのCONTRIBUTING.mdファイルに記載されている他のガイドラインに従ってください。
  • コードを送信する前に単体テストを実行します。
  • RFCスポンサーと協力して、新しいコードを上陸させます。

バーを高く保つ

私たちはすべての寄稿者を励まして祝いますが、RFCの受け入れの基準は意図的に高く保たれています。新しい機能は拒否されるか、次のいずれかの段階で大幅な修正が必要になる場合があります。

  • 関連するメーリングリストでの最初の設計会話。
  • スポンサー募集の失敗。
  • フィードバック段階での重大な反対意見。
  • 設計レビュー中にコンセンサスを達成できなかった。
  • 実装中に発生する懸念(例:下位互換性を実現できない、メンテナンスに関する懸念)。

このプロセスがうまく機能している場合、RFCは後の段階ではなく、前の段階で失敗することが予想されます。承認されたRFCは実装のコミットメントを保証するものではなく、提案されたRFC実装の受け入れは通常のコードレビュープロセスの対象となります。

このプロセスについて質問がある場合は、開発者のメーリングリストで質問するか、 テンソルフロー/コミュニティに問題を報告してください