proposal

GRPC RFC

介紹

在繼續之前，請閱讀GRPC組織的治理規則和貢獻指南。

該回購包含需要預先設計的GRPC的實質特徵更改的設計建議。前期設計過程的目標是：

• 在即將發生的變化及其周圍的設計注意事項方面，為社區提供了越來越多的可見性。
• 提供推理更大的變化“集合”的能力，這些變化太大，無法在問題中或公關中涵蓋。
• 建立一個一致的過程，以實現社區對大型變化的結構化參與，尤其是那些影響多個運行時間和實施的過程。

先決條件

對於需要設計的GRPC的任何重大更改，需要遵循此過程。被認為重要的變化可能是：

• 需要在運行時和語言中實現的功能。
• 影響GRPC產品實施方式的過程更改。
• 破壞公共API的變化（即SEMVER主要更改）。

過程

1. 分叉存儲庫並複制模板grfc-template.md。
2. 將其重命名為$CategoryName-$Summary ，例如： 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的新作品的更新。通過整個過程，需要將討論保存到郵件列表中的指定線程，以避免分裂對話。鼓勵所有者在此期間對提案的盡可能多的反饋。公關評論應僅限於格式和詞彙。
7. 如果在評論期內批准者認為達成共識，則批准者將標記為最終提案，並將其分配為GRFC編號。一旦分配了這一點（作為討論的關閉的一部分），所有者將更新公關狀態為最終狀態並提交PR。不得擠壓提交；提交歷史記錄是對提案的更改。

批准者

• 默認情況下， a11r是批准者，除非其他批准者以每個批准者為單位分配。
• 如果指定的批准者和所有者無法令人滿意地解決問題，則最終批准者仍然是a11r 。

建議類別

提案應按越來越多的順序編號。

• #An影響所有語言。
• #Pnn影響過程，例如提案過程本身。
• #Lnnn語言對外部API或平台支持的特定更改。
• #Gnnnn協議級別更改。

提案狀態

1. 每個無所事事的候選人都從Draft國家開始。
2. 在接受審查並將其發布給小組後，它進入了In Review狀態。
3. 一旦將其批准由仲裁者提交，它就會進入Final狀態。僅允許次要更改（批准者還符合次要的資格）。
4. 如果需要重新審視提案，則可以將其轉移回Draft或In Review狀態。如果在實施過程中發現問題，可能會發生這種情況。在這一點上，必須遵循上述審查過程。
5. 一旦提案是Final ，如果已通過一種語言實施，則可以將其更新為已列出的實施語言Implemented的狀態。 （不需要清單版本。）