• 起始日期：2018-06-28
  • RFC PR: (留空)
  • 追蹤議題: (留空)

摘要

在 Rust 與 WebAssembly 領域工作小組中採用簡化版的 Rust RFC 流程。RFC 流程將為所有利害關係人提供一個單一的地方來決定整個生態系統的重大變更和新增功能。

動機

有些決策會對整個 Rust 和 WebAssembly 生態系統產生廣泛的影響，因此有許多利害關係人應該在決策中發表意見，並對提案和設計提供反饋。目前，這些決策往往是在任何本地儲存庫的拉取請求或議題追蹤器中做出的。這使得利害關係人難以掌握這些決策，因為他們需要關注許多不同的地方。對於儲存庫所有者或團隊來說，也很難確定生態系統是否支持某個功能。

採用此 RFC 流程後，利害關係人應該更容易掌握生態系統中的重大變更和功能。此外，Rust 和 WebAssembly 生態系統中特定儲存庫的維護者應該有信心，在經過 RFC 流程後，他們已經徵求了所有參與者的反饋，並且不會收到那些認為自己沒有被諮詢的用戶的憤怒錯誤報告。每個人都應該對生態系統的發展方向有共同的信心。

詳細說明

目前，rustwasm 組織內儲存庫的治理遵循這些規則來描述合併拉取請求的政策

除非另有說明，否則每個 rustwasm/* 儲存庫都具有以下一般政策

  • 所有拉取請求在合併之前都必須至少由一位相關團隊成員或儲存庫協作者審查和批准。

  • 關於設計、架構、重大變更、權衡取捨等更大、更細微的決策由相關團隊和/或儲存庫協作者達成共識。換句話說，關於那些不是對專案中已存在事物的直接改進或錯誤修復的決策。

此政策將拉取請求歸類為「更大、更細微...」的變更或非此類變更（我們從現在開始將使用「重大」）。當變更不重大時，只需要一位團隊成員批准即可。當變更更大且更重大時，相關團隊將就如何進行達成共識。

此 RFC 旨在將重大變更進一步細分為僅影響儲存庫本身維護的變更（因此僅對維護者而言是重大的），以及對外部用戶和更大的 Rust 和 WebAssembly 社群產生影響的重大變更。對於內部重大的變更，我們不打算改變目前的政策。對於具有外部影響的重大變更，我們將採用輕量級版本的 Rust RFC 流程。

何時需要 RFC？

如果您打算對rustwasm 組織內的任何儲存庫或 RFC 流程本身進行外部重大的變更，則需要遵循 RFC 流程。「重大」變更的構成基於社群規範不斷發展，並且根據您提議變更的生態系統部分而有所不同，但可能包括以下內容

  • 刪除或對廣泛使用的公共 API 進行重大變更。
  • 以新方式擴展公共 API 的公共 API 新增功能（即，不僅僅是「我們為 ThisThing 實現 SomeTrait，也為 RelatedThing 實現 SomeTrait」）。

有些變更不需要 RFC

  • 改寫、重新組織、重構或其他「改變形式但不改變含義」的變更。
  • 嚴格改進客觀、數值質量標準的添加（例如，消除警告、提高速度、更好的平台覆蓋率、更多的並行性、捕獲更多錯誤等）。
  • 只有其他維護者可能會注意到的添加，並且對用戶保持不可見。

如果您在沒有經過 RFC 流程的情況下提交拉取請求來實作新功能，則可能會被禮貌地要求先提交 RFC。

RFC 流程步驟
  • Fork RFC 儲存庫。
  • 將 000-template.md 複製到 text/000-my-feature.md（其中「my-feature」是描述性的。不要 yet 分配 RFC 編號）。
  • 填寫 RFC。仔細考慮細節：沒有提出令人信服的動機、沒有證明理解設計的影響或對缺點或替代方案不誠實的 RFC 往往會受到不好的評價。
  • 提交拉取請求。作為拉取請求，RFC 將收到來自更大社群的設計反饋，作者應準備好根據反饋進行修改。
  • 每個新的 RFC 拉取請求都將在下一次 Rust 和 WebAssembly 領域工作小組會議中進行分類，並分配給一個或多個@rustwasm/* 團隊。
  • 建立共識並整合反饋。獲得廣泛支持的 RFC 比沒有收到任何評論的 RFC 更有可能取得進展。請隨時聯繫 RFC 受讓人，以獲得識別利害關係人和障礙的幫助。
  • 團隊將盡可能在拉取請求本身的評論線程中討論 RFC 拉取請求。離線討論將在拉取請求評論線程中進行總結。
  • RFC 很少會在不變的情況下通過此流程，尤其是在顯示替代方案和缺點時。您可以對 RFC 進行大小修改，以澄清或更改設計，但請將更改作為拉取請求的新提交，並在拉取請求上留下評論來解釋您的更改。具體來說，請勿在提交在拉取請求上可見後壓縮或變基提交。
  • 在某個時候，子團隊的成員將提出「最終評論期動議」（FCP），以及 RFC 的處置方式（合併、關閉或推遲）。
    • 當已經討論了足夠多的權衡取捨，團隊能夠做出決定時，就會採取此步驟。這並不需要 RFC 線程中的所有參與者達成共識（這可能是無法做到的）。但是，支持 RFC 處置的論點需要已經清楚地闡明，並且在團隊之外不應該有強烈的反對意見。團隊成員在採取此步驟時會運用他們的最佳判斷，而 FCP 本身確保利害關係人在過早做出決定時有足夠的時間和通知來反駁。
    • 對於討論時間較長的 RFC，在提出 FCP 動議之前，應先發表一個總結性評論，試圖闡明討論的現狀和主要的權衡取捨/分歧點。
    • 在實際進入 FCP 之前，團隊的所有成員都必須簽字同意；這通常是許多團隊成員首次完整審查 RFC 的時間點。
  • FCP 持續七個日曆日。它也被廣泛宣傳，例如在"Rust 和 WebAssembly 本週" 在 Rust 和 WebAssembly 博客上的一期中。這樣，所有利害關係人都有機會在做出決定之前提出任何最終的反對意見。
  • 在大多數情況下，FCP 期間是安靜的，RFC 要麼被合併，要麼被關閉。但是，有時會提出新的實質性論點或想法，FCP 被取消，RFC 回到開發模式。

從 RFC 到實作

一旦 RFC 被合併，它就變成了「活躍的」，然後作者可以實作它並將該功能作為拉取請求提交到相關的儲存庫。被「活躍」並不是橡皮圖章，特別是仍然不意味著該功能最終會被合併；它確實意味著原則上所有主要利害關係人都同意該功能並且願意合併它。

此外，給定的 RFC 已經被接受並且是「活躍的」這一事實並不意味著它的實作被賦予了什麼優先級，也不意味著是否有開發人員被分配了實作該功能的任務。雖然 RFC 的作者也編寫實作並不是必要的，但它是迄今為止看到 RFC 完成的最有效方法：作者不應該期望其他專案開發人員會承擔實作他們已接受的功能的責任。

可以通過後續的拉取請求來修改「活躍的」RFC。我們努力以反映功能最終設計的方式編寫每個 RFC；但流程的性質意味著我們不能期望每個合併的 RFC 在下一個主要版本發布時都能實際反映最終結果。

一般來說，一旦被接受，RFC 不應該進行實質性的更改。只有非常小的更改才能作為修正案提交。更實質性的更改應該是新的 RFC，並在原始 RFC 中添加註釋。

原理和替代方案

決策的設計空間非常大，從民主到專制等等。

Forking 和簡化 Rust 的 RFC 流程是實用的。我們不是從頭開始設計決策流程，而是採用一個現有的、運作良好的流程，並根據我們的需求進行調整。許多 Rust 和 WebAssembly 的利害關係人已經熟悉它。

與 Rust RFC 流程的主要區別是

  • FCP 持續七個日曆日而不是十個。這反映了我們希望有一個比 Rust 的 RFC 流程更輕量級、更快速的流程。
  • RFC 模板更短，並且將 Rust RFC 模板中不同的部分合併到單個部分中。同樣，這反映了我們希望有一個更輕量級的流程，在這個流程中，我們不需要像 Rust RFC 有時那樣詳細說明（也許不包括此 RFC）。

RFC 開發和 RFC 後實作的階段與 Rust RFC 流程基本相同。我們發現，Rust RFC 流程幾乎每個階段的動機都同樣適用於 Rust 和 WebAssembly 領域。我們原本希望大大簡化各個階段，例如，我們最初考慮刪除 FCP，直接簽署同意接受或不接受 RFC。但是，FCP 的存在是為了 (1) 允許利害關係人表達尚未提出的任何最終擔憂，以及 (2) 幫助執行「無新理由」規則。這兩點同樣適用於 Rust 和 WebAssembly 領域工作小組和生態系統，就像它們適用於 Rust 本身一樣。

我們也可以避免採用 RFC 流程，並通過允許每個儲存庫的團隊或所有者成為生態系統中自己角落的獨裁者來更快地行動。但是，這將導致有價值的反饋、意見和見解無法表達，並且會做出狹隘的決定。

未解決的問題

  • 我們會使用@rfcbot嗎？如果可以，我們可能應該使用它，但这可以与是否接受此 RFC 分开决定。

  • 如何最好地宣傳新的 RFC 和 FCP？我們是否應該讓「Rust 和 WebAssembly 本週」實際上每週發布一次，而不是每隔一周發布一次？FCP 長度和 TWiRaWA 發布頻率之間的互動似乎很重要。