Skip to content

Latest commit

 

History

History
56 lines (35 loc) · 3.61 KB

RFC-Collections.md

File metadata and controls

56 lines (35 loc) · 3.61 KB
Raw

Request Of Comments (RFCs)

RFC is a widely used policy for open source projects to make important design decisions. This article introduces the RAF RFC policy, and everyone is encouraged to submit an RFC for your awesome ideas!

What is an RFC. Request for Comments, or RFC, is a stage in open source community, in which developers propose ideas and request feedbacks from the community.

Why RFC. Writing RFCs, although adds to the overhead of documentation writing, enjoys the benefit of visibility, trust earning, early correction for potential mistakes and future memorization.

Levels of RFC Readiness

Inspired by the data readiness levels in machine learning [1], RFCs in RAF are categorized by levels of readiness in the similar way. An RFC is "accepted" means that it comes at least A3, "closed" means it is in level D or S; "work in progress" means A0-A2; "stabilized" means B1 or B2. Note that it is not necessary for an RFC to stabilize, unless it fundamentally changes the system, or adds a significant functionality that may affect future users or developers.

  • D: Deprecated, which means that agreement does not happen for now.
  • S: Superseded, which means there are better ideas proposed and the community agree to close the current one.
  • A0: On plan, no formal ideas or implementation.
  • A1: Formal ideas proposed.
  • A2: Formal implementation proposed.
  • A3: Implementation is merged into the master branch.
  • B1: Refactor has been done to stabilize the implementation of the RFC.
  • B2: The RFC is formally documented into developer's guide.

RFC Process (A2-B2)

Here we explain the RFC process starting from A2. For A0 and A1 RFCs, please also feel free to open an issue to describe your idea. When the idea becomes more concrete and could move to A2, you could close the old issue and follow the following steps to open a formal issue.

Step 1. Open an RFC Issue (A2)

When you have an awesome idea that could make RAF better, the first step is to open an issue in the repository. The issue title should be [RFC] Your Awesome Idea Title. In the issue body, please describe your idea clearly. You are encouraged but not limited to follow this template when drafting an RFC:

  • Motivation and Challenge: Why the existing system/solution is not good enough and we need this RFC? It would be great to draft this part with a driving example for better illustraction.
  • Proposed Methodology: Introduce your approach indetails.
  • Prove of Concept or Initial Results: Any prototype implementations or experiemental results to support your idea.
  • Milestones: A checklist of milestones that specify what we could expect at each stage.
  • Progress Tracking: A checklist of progress tasks, including investigation, PR sending, evaluation, etc.

At the end of the issue, please tag awslabs/raf-reviewer.

Step 2. Review (A2)

Everyone in the community are welcome to review and comment the RFC. We recommend to wait for about a week or two to collect feedbacks, and

Step 3. Implementation (A3)

You can now start implementing the proposed solution and sending PRs. Please remember to mention the RFC issue in each sent PR, and remember to check the progress in the RFC issue after each PR merged.

Step 4. Done (B1, B2)

When all proposed tasks are done, the final task is checking the RFC issue and whether there require any document updating. Once everything is done, you could close the RFC issue.

References

[1] Lawrence, Neil D. "Data readiness levels." arXiv preprint arXiv:1705.02245 (2017).