Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

RFC-0001：RFC 過程

  • 狀態：已實現
  • 拉取請求：https://github.com/asterinas/asterinas/pull/2365/
  • 提交日期：2025-08-24
  • 批准日期：2025-09-05

摘要

The “RFC” (request for comments) process is intended to provide a consistent, transparent, structured path for the community to make “big” decisions. For example, the RFC process can be used to evolve the project roadmap and the system architecture.

動機

As the Asterinas project grows in scale and community size, an informal decision-making process becomes insufficient. A formalized process is crucial for maintaining the quality and coherence of the project. Several highly successful open-source projects have demonstrated the value of such a process, including Rust (RFCs), Fuchsia (RFCs), Python (Python Enhancement Proposals or PEPs), and Kubernetes (Kubernetes Enhancement Proposals or KEPs).

採用正式的 RFC 過程將會：

  • 提升決策品質： 透過要求詳細的提案與公開討論，我們可以確保決策經過深思熟慮、技術上可行，並兼顧廣泛的觀點。
  • 促進共識：此過程提供了一個清晰的框架，讓社群成員能匯聚一堂、討論不同觀點，並針對重要議題達成共識。
  • Create design records: Approved RFCs will serve as a historical archive, documenting the design choices made and the reasoning behind them. This is invaluable for new contributors and for future reference.

By introducing this process, we aim to support the healthy and sustainable growth of the Asterinas project.

設計

何時應遵循 RFC 過程

RFC 過程應適用於對 Asterinas 的任何「重大」變更。需要 透過 RFC 進行變更的範例包括：

  • 啟動與 OSTD 和 OSDK 具有同等重要性的全新頂層子專案。
  • 定義或大幅修改專案路線圖與目標。
  • Establishing or changing project-wide norms, such as this RFC process itself or coding style guides.
  • 提出重大的架構設計，例如框內核架構或安全方針注入。
  • Introducing changes that affect user-space programs, such as adding a non-Linux system call or feature.

Examples of changes that do not require an RFC include:

  • Proposing a design whose impact is confined to a single sub-project or module. If the design is significant or non-trivial, submit a design proposal on Github Issues for discussion.
  • Adding well-understood features with established patterns, such as a standard Linux system call or a device driver.
  • Refactoring existing code, fixing bugs, or improving performance.

When in doubt, it is best to consult with the project maintainers using the methods described in the next section.

RFC 過程的運作方式

RFC 過程由幾個不同的階段組成：

社交化階段

Before investing the time to write a full RFC, it is highly recommended to socialize the core idea with the community. This helps gauge interest, gather early feedback, and refine the proposal. Good venues for this include:

  • Starting a discussion on the project’s GitHub Discussions page.
  • Posting a “Pre-RFC” document to solicit more detailed feedback.
  • 直接與重要貢獻者、程式碼擁有者或維護者溝通。

Having support from at least a few other community members is a strong signal that the idea is ready for a formal RFC. Additionally, having a proof-of-concept implementation or identifying individuals committed to the implementation can strengthen the proposal.

草稿階段

當您準備好繼續進行時，請創建一份正式的 RFC 文件。

  1. 分叉 asterinas/asterinas 儲存庫。
  2. In the rfcs directory, copy rfc-template.md and rename it to 0000-your-rfc-title.md. The 0000 is a placeholder for the RFC number, which will be assigned later.
  3. Fill out the template with your proposal. The template provides a solid structure, but feel free to adapt it to best suit your proposal.

疊代階段

將您的 RFC 草案以拉取請求（PR）的形式提交至 Asterinas 儲存庫。一旦 PR 開啟，正式的審核過程即將開始：

  • A project maintainer will be assigned as the facilitator for the RFC. The facilitator’s role is to guide the discussion, ensure it remains productive, and ultimately determine when consensus has been reached.
  • 我們鼓勵社群的所有成員審閱提案，並透過拉取請求上的評論提供建設性的反饋。
  • RFC 作者有責任參與反饋互動、回應疑慮，並更新 RFC 文字以反映不斷演進的共識。

投票階段

當討論趨於一致且主要的反饋意見皆已處理完畢時，作者可以請求協調人發起最終投票。

  • 投票開放給所有專案維護者以及頂層子專案的程式碼擁有者。詳情請參見 CODEOWNERS 檔案。
  • 投票者可以表達「贊成」或「反對」。
  • The final decision will be based on a rough consensus as determined by the facilitator. This means that while unanimous agreement is not required, any major objections must be addressed.

如果最終決定為批准：

  1. The facilitator will assign an unique RFC number.
  2. The author will update the RFC’s file name with the assigned RFC number. The author should also update the metadata fields of the RFC.
  3. The facilitator will merge the pull request.

維護階段

Once an RFC is approved, the proposed changes are ready for implementation. When the corresponding work is completed and merged, the RFC’s status is updated from “approved” to “implemented.”

Approved RFCs are considered immutable historical records of design decisions. As such, only minor corrective edits like fixing typos or broken links are allowed.

針對現有 RFC 的重大變更或修正，必須透過全新的 RFC 提出。這項新提案也可用於正式廢止先前的 RFC，在這種情況下，原 RFC 的狀態將更新為「已棄用」。

授權條款

All RFCs submitted to the Asterinas project are licensed under Apache License, Version 2.0. This license is more permissive than the MPL license used for the Asterinas code.

缺點

Introducing a formal RFC process can increase the overhead for making changes to the project. The process is intentionally deliberate, which may slow down the pace of development for major features. There is also a risk that the process could become overly bureaucratic if not managed carefully. For contributors, the effort required to write a high-quality RFC and see it through the review process can be significant.

Prior Art and References

Asterinas 的 RFC 過程深受以下兩個開源專案成熟過程的啟發：

  • Rust RFC 過程：整體結構與理念皆緊密參考 Rust 的 RFC 過程。
  • Fuchsia RFC Process: We have drawn on the Fuchsia process for its clear definition of roles and its emphasis on transparent decision-making.