RFC-0000: RFC

[zmzlois]

Summary

The "RFC" (request for comments) process is intended to provide a consistent and controlled path for changes to Zephyr, the platform and products (such as new features) so that all stakeholders can be confident and have a coherent understanding of the direction of the project.
Many changes, including bigger feature proposals, bug fixes and documentation improvements, can be implemented and reviewed via RFC workflow.

---

Motivation

Benefits today

• Regulate the current feature workflow
• Aligning contributor and stakeholder's expectation and implementation
• Tracking progress for big features and making sure we deliver it to meet standards

Benefits in the future

• Easier for future collaborators, colleagues to track decision making process and have an Architectural Decision Making Record
• Foster a open, collaborative culture (maybe also practice English?) where some parts of our codebase will be open sourced.

---

Guide-level explanation

1. Heading

• Start Date: (fill me in with today's date, YYYY-MM-DD)
• Issue: The tracking issue of this RFC. In a tracking issue, you can provide a checklist of current existing issues that this RFC tries to resolve of some tasks included in this RFC.

2. Summary

• One paragraph explaining the feature, why it is needed.

3. Motivation

• Why are we doing this?
• What use cases does it support?
• What is the expected outcome?

4. Guide-level explanation

• This is the proposal
• Explain the proposal as if it was already implemented in the product and you were teaching it to another developer to use it
• • What behavior changes you are bringing? What's the behavior today? What's the behavior after changes?

5. Reference-level explanation

• This is the technical portion of the RFC, include code snippet or where this change will happen
  -- ByteDance WebInfra
  -- Remix RFC example: Single Data Fetch

6. Drawbacks (Optional)

• Why should we not do this?

7. Rationale and alternatives

• Why is this design the best in the space of possible designs?
• What other designs have been considered and what is the rationale for not choosing them
• What is the impact of not doing this?

8. Prior art (Previous research)

• Discuss prior art, both the good and the bad, about this proposal
• It can be known as how other similar features work in relevant products or toolings, include code reference/permalink from other tooling
• Reference

9. Unresolved questions (Optional)

• What related issues do you consider out of scope for this RFC that could be addressed in the future independently of the solution? (aka might be problem exists but incrementally fixable)

10. Future possibilities (Optional)

• Think about what the natural extension and evolution of your proposal would be and how it would affect Zephyr's architecture and project as a whole in a holistic way.

---

RFC Workflow

1. Create a new RFC discussion
   Create a new RFC in discussion and choose RFC for the category. An RFC should eb titled as RFC-0000: Name of the RFC
2. Write an RFC
   If an RFC is in the status of working progress, you should label it as WIP by prepend (WIP) to the title (WIP) RFC-0000: Name of the RFC
3. Ready for review
   After an RFC is done, you should ask for a review from team members. At this point in time feel free to comment and get all questions resolved
4. Finish reviewing
   For each reviewer, after all the questions you asked have been resolved, tap thumb up 👍 button at the bottom of the discussion, indicated the RFC had been reviewed by you.
5. Start a discussion
   After finishing review, initiate a meeting with team members/or talk over it over code review or planning meeting to walk through the whole RFC. Details not covered by RFC can be patched to the discussion of an RFC around this time.
6. No further questions
   If there are no further questions for this RFC, the author of an RFC should label the RFC as RFC-approved
7. Create a tracking issue
   Create an issue for tracking issues of this RFC. It can contain the issue we already have and the tasks we should do in order to implement this RFC. It will be regarded as a checklist of implementing this RFC as a whole. After the tracking issue is created, the author of the RFC should add it back to the discussion.
8. Implement the RFC
   Issues in the tracking issue of the RFC can be assigned to other members, after which is done the RFC should be labeled as RFC-implemented
9. After implementation
   An implemented RFC should be archived to the docs/rfcs

---

RFC Template

A separate RFC template should be provided in the discussion section.
RFC-0001: Template

---

Drawbacks

The main reason for us to use the discussion section of the GitHub project is to simplify the procedure under the current circumstances. However, this method has its drawbacks: Tracking the changes of an RFC is very hard. We cannot apply the comment to a certain line.

---

Rationale and alternatives

RFC contributing guides for other projects mostly using Pull Requests, which enables developers to use the whole functionalities of GitHub to comment / review changes / approve the RFC.