From e2c501fd87fd4188cdfd6097129833b5eb6cefd1 Mon Sep 17 00:00:00 2001 From: Jeeyong Um Date: Fri, 19 Jul 2024 23:22:11 +0900 Subject: [PATCH] Apply corrections for RFC Creation Process --- rfc/PROCESS.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/rfc/PROCESS.md b/rfc/PROCESS.md index 204edbb..e48c539 100644 --- a/rfc/PROCESS.md +++ b/rfc/PROCESS.md @@ -6,19 +6,19 @@ 4. Add an entry to the list in the [README](./README.md) file. 5. Create a Pull Request to propose a new RFC. -## What is a RFC? +## What is an RFC? -A RFC is a sort of async whiteboarding session. It is meant to replace the need for a distributed team to come together to make a decision. Currently, the Noir team and contributors are distributed around the world. The team conducts working groups to have a synchronous discussion and a RFC can be used to capture the discussion for a wider audience to better understand the changes that are coming to the software. +An RFC is a sort of async whiteboarding session. It is meant to replace the need for a distributed team to come together to decide. Currently, the Noir team and contributors are distributed around the world. The team conducts working groups to have a synchronous discussion, and an RFC can be used to capture the discussion for a wider audience to better understand the changes that are coming to the software. -The main difference the Noir is defining as a differentiation between RFCs and ADRs is that one is to come to consensus and circulate information about a potential change or feature. An ADR is used if there is already consensus on a feature or change and there is not a need to articulate the change coming to the software. An ADR will articulate the changes and have a lower amount of communication. +The main difference the Noir defines between RFCs and ADRs is that an RFC is to come to consensus and circulate information about a potential change or feature. An ADR is used if there is already consensus on a feature or change and there is no need to articulate the change coming to the software. An ADR will articulate the changes and require less communication. ## RFC life cycle -RFC creation is an **iterative** process. A RFC is meant as a distributed collaboration session, it may have many comments and is usually the by-product of no working group or synchronous communication. +RFC creation is an **iterative** process. An RFC is meant as a distributed collaboration session, it may have many comments and is usually the by-product of no working group or synchronous communication. 1. Proposals could start with a new GitHub Issue, be a result of existing Issues or a discussion. -2. A RFC doesn't have to arrive to `main` with an _accepted_ status in a single PR. If the motivation is clear and the solution is sound, we SHOULD be able to merge it and keep a _proposed_ status. It's preferable to have an iterative approach rather than long, not merged Pull Requests. +2. An RFC doesn't have to arrive to `main` with an _accepted_ status in a single PR. If the motivation is clear and the solution is sound, we SHOULD be able to merge it and keep a _proposed_ status. It's preferable to have an iterative approach rather than long, not merged Pull Requests. 3. If a _proposed_ RFC is merged, then it should clearly document outstanding issues either in the RFC document notes or in a GitHub Issue. @@ -28,7 +28,7 @@ RFC creation is an **iterative** process. A RFC is meant as a distributed collab 6. If there is consensus and enough feedback then the RFC can be accepted. -> Note: A RFC is written when there is no working group or team session on the problem. RFCs are meant as a distributed whiteboarding session. If there is a working group on the proposal there is no need to have a RFC as there is synchronous whiteboarding going on. +> Note: An RFC is written when there is no working group or team session on the problem. RFCs are meant as a distributed whiteboarding session. If there is a working group on the proposal, there is no need to have an RFC as there is synchronous whiteboarding going on. ### RFC status @@ -48,9 +48,9 @@ DRAFT -> PROPOSED -> LAST CALL yyyy-mm-dd -> ACCEPTED | REJECTED -> SUPERSEDED b ABANDONED ``` -* `DRAFT`: [optional] a RFC which is work in progress, not being ready for a general review. This is to present early work and get early feedback in a Draft Pull Request form. -* `PROPOSED`: a RFC covering a full solution architecture and still in review - project stakeholders haven't reached an agreement yet. -* `LAST CALL `: [optional] clearly notify that we are close to accepting updates. Changing a status to `LAST CALL` means that social consensus (of Noir maintainers) has been reached and we still want to give it time to let the community react or analyze. +* `DRAFT`: [optional] an RFC which is work in progress, not being ready for a general review. This is to present early work and get early feedback in a Draft Pull Request form. +* `PROPOSED`: an RFC covering a full solution architecture and still in review - project stakeholders haven't reached an agreement yet. +* `LAST CALL `: [optional] clearly notify that we are close to accepting updates. Changing a status to `LAST CALL` means that social consensus (of Noir maintainers) has been reached, and we still want to give it time to let the community react or analyze. * `ACCEPTED`: RFC which will represent a currently implemented or to be implemented architecture design. * `REJECTED`: RFC can go from PROPOSED or ACCEPTED to rejected if the consensus among project stakeholders decides so. * `SUPERSEDED by RFC-xxx`: RFC which has been superseded by a new RFC.