RFC-009: RFC

[h-a-n-a]

Summary

The "RFC" (request for comments) process is intended to provide a consistent and controlled path for changes to Rspack (such as new features) so that all stakeholders can be confident about the direction of the project.

Many changes, including bug fixes and documentation improvements can be implemented and reviewed via the new Discussion RFC workflow.

Motivation

Regulate the chaotic RFC section.

Guide-level explanation

Sections of an RFC

1. Heading
   • Start Date: (fill me in with today's date, YYYY-MM-DD)
   • Rspack Issue: The tracking issue of this RFC, see this example. In a tracking issue, you can provide a checklist of current existing issues that this RFC tries to resolve or some tasks included in this RFC
2. Summary: One paragraph explanation of the feature.
3. Motivation: Why are we doing this? What use cases does it support? What is the expected outcome?
4. Guide-level explanation: Explain the proposal as if it was already included in the Rspack and you were teaching it to another developer using Rspack.
5. Reference-level explanation: This is the technical portion of the RFC.
6. Drawbacks: 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: Discuss prior art, both the good and the bad, about this proposal. Also can be known as how other bundler works
9. Unresolved questions: What related issues do you consider out of scope for this RFC that could be addressed in the future independently of the solution that comes out of this RFC?
10. Future possibilities: Think about what the natural extension and evolution of your proposal would be and how it would affect the Rspack 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 be titled as RFC-0000: Name of the RFC.
2. Write an RFC: If an RFC is in the status of working in progress, you should label it as WIP by simply 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 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, you should tap the thumbs up 👍 button at the bottom of the discussion, which indicates the RFC had been reviewed by you.
5. Start a discussion: After an RFC is finished its review, It's time to initiate a meeting with team members and walk through the whole RFC. Details not covered by RFC can be patched to the discussion of an RFC.
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 for this RFC. This can contain the issue that 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 the implementation: An implemented RFC should be archived to the docs/rfcs.

RFC Template

A separate RFC template should be provided in the discussion section.

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 is mostly using Pull Requests, which enables developers to use the whole functionalities of GitHub to comment / review changes / approve the RFC.