Hi, great suggestions and here are my thoughts on this
---
* 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.
I like Xuanwo’s idea to reuse the original RFC rules. Apart from that, for
anything as significant, I
suggest we have an RFC as well, such as architectural changes. Although some
words seem
to be vague, raising an RFC before actual implementation would be better if the
idea is considered
complex.
---
* How to determine whether to accept an RFC or not?
I think a majority vote on everyone who is involved in the 2nd phase would be a
good idea. We could
also have a vote minimum threshold at 2.
P.s. The voting could happen in the PR.
---
* 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.
For this part, I think it’s better if we could involve more
people so IMO github issue(I prefer this)
and github discussion are good places to start.
---
Best,
Xinyou
From: Suyan <[email protected]>
Date: Monday, October 23, 2023 at 05:09
To: [email protected] <[email protected]>
Subject: [DISCUSS]OpenDAL RFC Policy
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://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopendal.apache.org%2Fdocs%2Frust%2Fopendal%2Fdocs%2Frfcs%2Findex.html&data=05%7C01%7C%7C9ebc54db948b4dd5816908dbd3a7c6f6%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638336489781447548%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=pXlB1NNIG1zA37jI38D9BTs0%2Fyn%2BgeyM89kXmhRf9v0%3D&reserved=0<https://opendal.apache.org/docs/rust/opendal/docs/rfcs/index.html>
2. Related PRs:
https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fincubator-opendal%2Fpulls%3Fpage%3D1%26q%3Dis%253Apr%2B%2Bsort%253Aupdated-desc%2Bin%253Atitle%2BRFC&data=05%7C01%7C%7C9ebc54db948b4dd5816908dbd3a7c6f6%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638336489781603777%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=sO2CoTg%2BaGyDH8hp8l%2ByvCkEX2V%2F6CZfRbZMxT%2FZ1QA%3D&reserved=0<https://github.com/apache/incubator-opendal/pulls?page=1&q=is%3Apr++sort%3Aupdated-desc+in%3Atitle+RFC>
