You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@opendal.apache.org by Suyan <su...@apache.org> on 2023/10/23 09:08:59 UTC
[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://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
Re: [DISCUSS]OpenDAL RFC Policy
Posted by Suyan <su...@apache.org>.
Hi all,
Thank you for your participation in this discussion.
I've submitted a PR[1] based on the thread's topic and
would appreciate your review.
Any feedback and suggestions are welcome.
I look forward to hearing from you.
Sincerely,
Suyan
--- References ---
[1]: https://github.com/apache/incubator-opendal/pull/3748
Suyan <su...@apache.org> 于2023年10月23日周一 17:08写道：
>
> 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
Re: [DISCUSS]OpenDAL RFC Policy
Posted by Suyan <su...@apache.org>.
> 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 <xu...@apache.org> 于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
Re: [DISCUSS]OpenDAL RFC Policy
Posted by Xuanwo <xu...@apache.org>.
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
Re: [DISCUSS]OpenDAL RFC Policy
Posted by Xinyou Ji <Je...@outlook.com>.
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 <su...@apache.org>
Date: Monday, October 23, 2023 at 05:09
To: dev@opendal.apache.org <de...@opendal.apache.org>
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>