> Previously, we adhered to the guideline that any **changes** to the opendal > public API required an RFC. Is it a good idea to reuse this rule?
I think reuse is good. We might need to raise a RFC if an Idea alone can't cover all about itself, need more details such as how to implement it. > All of mail list, github issues and discord are ok? All of these may be where the Idea is born, but we need to organize and document them. I think the github issue is a good choice to conduct the pre-review. It could also include the source of the discussion. > For instance, should we keep an RFC open for a minimum of three days? Should > we require at least three approvals? In order to try to make it possible for as many people as possible to see and join in the discussion, we can set some time limits and a lower limit on the number of votes. Sincerely, Suyan Xuanwo <[email protected]> 于2023年10月23日周一 17:53写道： > > Thanks for initiating the discussion! > > > 1. Significant feature changes: When there is an idea or suggestion > > for a major feature change, initiating an RFC allows for comprehensive > > discussion and review. This ensures that significant changes are > > carefully considered and receive broad recognition. > > 2. Architecture adjustments: If there are suggestions for adjusting or > > refactoring the project's architecture, RFC can be used to evaluate > > and discuss the feasibility and impact of these changes. > > 3. Important decisions: For situations that require important > > decision-making, RFC provides a platform for brainstorming and allows > > others to provide their opinions and suggestions, ultimately reaching > > a consensus. > > The content appears accurate but lacks practicality. Naturally, we require an > RFC for "Significant feature changes", "Architecture adjustments", and > "Important decisions". However, how do we define these terms and their > opposites? > > How about we adopt a straightforward rule for proposals? Previously, we > adhered to the guideline that any **changes** to the opendal public API > required an RFC. Is it a good idea to reuse this rule? Should we apply this > rule to all our released components (core, python, nodejs, java)? > > > 1. Idea proposal and pre-review: Before entering the formal discussion > > phase, we can have a pre-review stage. During this stage, we can > > carefully examine and evaluate the content of the RFC, raise > > questions, and provide suggestions. This helps identify potential > > issues and provides a better foundation for discussion. > > How should we conduct the pre-review? All of mail list, github issues and > discord are ok? > > > 3. Voting and decision-making: After the discussion phase, we can > > proceed with voting and decision-making based on the maintainer team's > > opinions and suggestions. This can be done through a simple majority > > principle or any other appropriate voting mechanism. The voting > > results will determine whether the RFC is accepted, and subsequent > > action plans will be decided accordingly. > > We need to establish clear standards for RFCs. For instance, should we keep > an RFC open for a minimum of three days? Should we require at least three > approvals? > > On Mon, Oct 23, 2023, at 17:08, Suyan wrote: > > Hi, all OpenDAL community members > > > > OpenDAL has using the RFC (Request for Comments) discussion system for > > some time now, but we still need to reach a consensus on certain > > details. > > > > Therefore, I would like to discuss two questions: > > > > 1. When we should initiate RFC discussions? > > 2. How to determine whether to accept an RFC or not? > > > > RFC is a proposal mechanism used to introduce new features, > > architectural changes, or important decisions. When someone has a new > > idea or suggestion, they can raise awareness and initiate discussions > > by proposing an RFC. An RFC should include a clear problem statement, > > objectives and motivations, as well as specific solutions or > > recommendations. This helps others understand the context and goals of > > the problem and provides a foundation for meaningful discussions. > > > > Regarding when to initiate RFC discussions, I suggest considering the > > following scenarios: > > > > 1. Significant feature changes: When there is an idea or suggestion > > for a major feature change, initiating an RFC allows for comprehensive > > discussion and review. This ensures that significant changes are > > carefully considered and receive broad recognition. > > 2. Architecture adjustments: If there are suggestions for adjusting or > > refactoring the project's architecture, RFC can be used to evaluate > > and discuss the feasibility and impact of these changes. > > 3. Important decisions: For situations that require important > > decision-making, RFC provides a platform for brainstorming and allows > > others to provide their opinions and suggestions, ultimately reaching > > a consensus. > > > > As for determining whether to accept an RFC for discussion and > > ensuring that RFC discussions are efficient and valuable, I propose > > the following steps: > > > > 1. Idea proposal and pre-review: Before entering the formal discussion > > phase, we can have a pre-review stage. During this stage, we can > > carefully examine and evaluate the content of the RFC, raise > > questions, and provide suggestions. This helps identify potential > > issues and provides a better foundation for discussion. > > 2. Discussion and feedback: Once an RFC enters the formal discussion > > phase, we can initiate a pull request (PR) and engage in in-depth > > discussions about the content, feasibility, and impact of the RFC. It > > is encouraged for everyone to actively participate and provide > > constructive feedback and opinions. This allows for a comprehensive > > assessment of the merits and feasibility of the RFC. > > 3. Voting and decision-making: After the discussion phase, we can > > proceed with voting and decision-making based on the maintainer team's > > opinions and suggestions. This can be done through a simple majority > > principle or any other appropriate voting mechanism. The voting > > results will determine whether the RFC is accepted, and subsequent > > action plans will be decided accordingly. > > > > These are the recommendations I propose regarding RFC discussions. > > > > If you have any questions or suggestions regarding RFC discussions, > > please feel free to raise them. > > > > Sincerely, > > Suyan > > > > --- References --- > > 1. Some RFCs we have accepted: > > https://opendal.apache.org/docs/rust/opendal/docs/rfcs/index.html > > 2. Related PRs: > > https://github.com/apache/incubator-opendal/pulls?page=1&q=is%3Apr++sort%3Aupdated-desc+in%3Atitle+RFC > > -- > Xuanwo
