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
