proposal

GRPC RFCS

導入

先に進む前に、GRPC組織のガバナンスルールと貢献ガイドラインをお読みください。

このレポは、前払いする必要があるGRPCの実質的な機能変更に関する設計提案が含まれています。先行設計プロセスの目標は次のとおりです。

• 今後の変更とそれらの周りの設計上の考慮事項について、コミュニティへの可視性を高めます。
• 問題またはPRでカバーするには大きすぎる変更のより大きな「セット」について推論する能力を提供します。
• 特に複数のランタイムと実装に影響を与える大きな変化に関するコミュニティによる構造化された参加のための一貫したプロセスを確立します。

前提条件

このプロセスには、設計が必要なGRPCへの大幅な変更のために従う必要があります。重要と見なされる変更は次のとおりです。

• ランタイムと言語にわたって実装が必要な機能。
• GRPC製品の実装方法に影響を与えるプロセスの変更。
• パブリックAPIの変更を破る（つまり、Semverの大きな変更）。

プロセス

1. レポをフォークし、テンプレートgrfc-template.mdをコピーします。
2. $CategoryName-$Summary 、eg。： A6-client-retries.mdに変更します（以下のカテゴリ定義を参照）
   • 言語固有の提案については、言語の名前を含めます： L##-$Language-$Summary 。標準名： core 、 cpp 、 csharp 、 go 、 java 、 node 、 objc 、 php 、 python 、 ruby 。
3. RFCを書きます。
4. プルリクエストを送信します。
5. GRPCチームの誰かが、このレビューの一環として承認者に割り当てられます。承認者が割り当てられたら、所有者はGRPC-IOに関するディスカッションを開始し、ディスカッションリンクでPRを更新する必要があります。これが完了した後、所有者はGRFCをIn Reviewの状態に更新する必要があります。承認者は、必要に応じてこのプロセスに沿って所有者を支援することが期待されています。
6. 少なくとも10営業日（最低コメント期間）の間、所有者はコメントに応答し、PRへの新しいコミットメントとしてRFCを更新することが期待されます。このプロセスを通じて、会話の分裂を避けるために、メーリングリストの指定されたスレッドにディスカッションを保持する必要があります。所有者は、この期間中に可能な限り提案に関するフィードバックを求めることをお勧めします。 PRコメントは、フォーマットと語彙に限定する必要があります。
7. コメント期間中に承認者が検討したコンセンサスがある場合、承認者は提案を最終としてマークし、GRFC番号を割り当てます。これが割り当てられたら（議論の閉鎖の一環として）、所有者はPRの状態を最終的に更新し、PRを提出します。コミットは押しつぶされてはなりません。コミット履歴は、提案に加えられた変更のログとして機能します。

承認者

• デフォルトでは、別の承認者が提案ごとに割り当てられない限り、 a11r承認者です。
• 割り当てられた承認者と所有者が問題を十分に解決できない場合、最終的な承認者はまだa11rです。

提案カテゴリ

提案には、増加する順序で番号が付けられます。

• #An an-すべての言語に影響します。
• #Pnn提案プロセス自体などのプロセスに影響します。
• #Lnnn外部APIまたはプラットフォームサポートの言語固有の変更。
• #Gnnnnプロトコルレベルの変更。

提案ステータス

1. すべてのコミットされていない提案候補者は、 Draft州で始まります。
2. レビューを受け入れてグループに投稿した後、 In Review状態に入ります。
3. アービターによる提出が承認されると、 Final状態になります。マイナーな変更のみが許可されています（マイナーとしての資格は承認者に残されます）。
4. 提案を再検討する必要がある場合、 DraftまたはIn Review状態に戻すことができます。これは、実装中に問題が発見された場合に発生する可能性があります。その時点で、上記のレビュープロセスに従う必要があります。
5. 提案がFinalになり、言語で実装されている場合、リストされた実装言語でImplementedステータスに更新できます。 （リストバージョンは必要ありません。）