You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Udo Kohlmeyer <ud...@vmware.com> on 2020/07/09 20:18:50 UTC
[Proposal] - RFC etiquette
Hi there Geode Dev's
I would like to propose the following changes to the RFC process that we have in place at the moment.
1. All submitted RFC’s will provide a minimum 2 week review period. This is to allow the community to review the RFC in a reasonable timeframe. If we rush things, we will miss things. I’d rather have a little more time spent on the RFC review and getting the approach “correct” than rushing the RFC and then at a later point in time (either at PR review or worse production issue) find out that the approach was less than optimal.
2. Add a new section to the RFC. I would like to propose this section to be labelled “Use Cases”. In this section I would like all submitters to describe the use case that this RFC is to fulfill. This would include all possible combinations (success and failure) and expected outcomes of each.
I hope with the additions to the RFC process and template we can better round out each RFC. Causing less delays later in the process and allowing all community members to actively participate in the review process regardless of technical skill level.
Thoughts or comments?
—Udo
Re: [Proposal] - RFC etiquette
Posted by Udo Kohlmeyer <ud...@vmware.com>.
Hi there Alberto,
I’m merely trying to improve the RFC process. We learn and improve. Get more community members to feel empowered to be able to review an RFC, not only from the perspective of is it technically feasible but also from a process and “business” sense.
Having a better understand of what we expect and component of system to do is paramount here, even if just from a high-level.
—Udo
On Jul 10, 2020, 1:08 AM -0700, Alberto Gomez <al...@est.tech>, wrote:
Hi Geode Devs,
First of all, Udo, thanks for your proposal. I am all up for what you are aiming at: "better round out each RFC. Causing less delays later in the process and allowing all community members to actively participate in the review process regardless of technical skill level."
Secondly, I think I am to blame for having given two little time to review the latest RFC I have published. I apologize for it. I felt the changes were too small, assumed that the solution was not problematic and as a result gave less than a week to review which I now think is too little even if the RFC content was small. This has probably triggered Udo's proposal so, in a way, it has not been such a bad thing 😉.
Regarding the concrete proposal to achieve the goal, I think the 2 week minimum period is very reasonable. The new use case section may help to have more community members actively participating but I am not sure that it will be the definitive measure. I feel that sometimes the lack of participation comes from lack of time because we're busy with other things and not so much with how the RFC proposal has been written. Anyhow, having an example of what this new section should look like would be helpful for new RFCs to be written.
Alberto
________________________________
From: Udo Kohlmeyer <ud...@vmware.com>
Sent: Thursday, July 9, 2020 10:18 PM
To: geode <de...@geode.apache.org>
Subject: [Proposal] - RFC etiquette
Hi there Geode Dev's
I would like to propose the following changes to the RFC process that we have in place at the moment.
1. All submitted RFC’s will provide a minimum 2 week review period. This is to allow the community to review the RFC in a reasonable timeframe. If we rush things, we will miss things. I’d rather have a little more time spent on the RFC review and getting the approach “correct” than rushing the RFC and then at a later point in time (either at PR review or worse production issue) find out that the approach was less than optimal.
2. Add a new section to the RFC. I would like to propose this section to be labelled “Use Cases”. In this section I would like all submitters to describe the use case that this RFC is to fulfill. This would include all possible combinations (success and failure) and expected outcomes of each.
I hope with the additions to the RFC process and template we can better round out each RFC. Causing less delays later in the process and allowing all community members to actively participate in the review process regardless of technical skill level.
Thoughts or comments?
—Udo
Re: [Proposal] - RFC etiquette
Posted by Alberto Gomez <al...@est.tech>.
Hi Geode Devs,
First of all, Udo, thanks for your proposal. I am all up for what you are aiming at: "better round out each RFC. Causing less delays later in the process and allowing all community members to actively participate in the review process regardless of technical skill level."
Secondly, I think I am to blame for having given two little time to review the latest RFC I have published. I apologize for it. I felt the changes were too small, assumed that the solution was not problematic and as a result gave less than a week to review which I now think is too little even if the RFC content was small. This has probably triggered Udo's proposal so, in a way, it has not been such a bad thing 😉.
Regarding the concrete proposal to achieve the goal, I think the 2 week minimum period is very reasonable. The new use case section may help to have more community members actively participating but I am not sure that it will be the definitive measure. I feel that sometimes the lack of participation comes from lack of time because we're busy with other things and not so much with how the RFC proposal has been written. Anyhow, having an example of what this new section should look like would be helpful for new RFCs to be written.
Alberto
________________________________
From: Udo Kohlmeyer <ud...@vmware.com>
Sent: Thursday, July 9, 2020 10:18 PM
To: geode <de...@geode.apache.org>
Subject: [Proposal] - RFC etiquette
Hi there Geode Dev's
I would like to propose the following changes to the RFC process that we have in place at the moment.
1. All submitted RFC’s will provide a minimum 2 week review period. This is to allow the community to review the RFC in a reasonable timeframe. If we rush things, we will miss things. I’d rather have a little more time spent on the RFC review and getting the approach “correct” than rushing the RFC and then at a later point in time (either at PR review or worse production issue) find out that the approach was less than optimal.
2. Add a new section to the RFC. I would like to propose this section to be labelled “Use Cases”. In this section I would like all submitters to describe the use case that this RFC is to fulfill. This would include all possible combinations (success and failure) and expected outcomes of each.
I hope with the additions to the RFC process and template we can better round out each RFC. Causing less delays later in the process and allowing all community members to actively participate in the review process regardless of technical skill level.
Thoughts or comments?
—Udo
Re: [Proposal] - RFC etiquette
Posted by Owen Nichols <on...@vmware.com>.
+1
Even for smaller changes that only need a PR (not a whole RFC) it's a good habit to include some detail about the use cases. Both reviewers and future committers benefit from thoughtful commit messages and PR descriptions that mention *why*, not just *what* was changed.
On 7/9/20, 6:15 PM, "Dave Barnes" <db...@apache.org> wrote:
+1
"Adding a section" (Udo's language) for Use Cases is a positive way of
encouraging RFC authors to provide that material, without saying it's an
iron-clad requirement. Exactly the right way to do it. Commenters can
request more detail when they review it.
On Thu, Jul 9, 2020 at 4:31 PM Donal Evans <do...@vmware.com> wrote:
> Udo,
>
> You're right, and I agree wholeheartedly with your proposal to give RFCs
> enough time and enough context for proper review by as many people as
> possible. Sorry if that didn't come across in my original reply.
> ________________________________
> From: Udo Kohlmeyer <ud...@vmware.com>
> Sent: Thursday, July 9, 2020 3:55 PM
> To: dev@geode.apache.org <de...@geode.apache.org>
> Subject: Re: [Proposal] - RFC etiquette
>
> Donal,
>
> You have very valid points. All of which only pertain to the “HOW” or “IF”
> an RFC should be written. This being a completely different problem to what
> I’m proposing. I’m willing to comment on any proposal that were to address
> these issues. :)
>
> This proposal is largely aimed at, if there is an existing RFC, we don’t
> try and rush it through and provide more context to reviewers to better
> comment on use case, technical approach or overall soundness of the
> proposal. If we keep aiming RFC’s at specialized technical knowledge, we
> will definitely lose reviewers who have not looked at that code in a long
> time. If the use case(s) are at least described than we can have many
> reviewers who can comment on the feature or technical approach without
> being intimate with all the inner workings of the system.
>
> I believe this approach will help with an overall better understanding of
> the systems behavior.
>
> —Udo
> On Jul 9, 2020, 1:46 PM -0700, Donal Evans <do...@vmware.com>, wrote:
> While I definitely approve of these proposals in principle (especially the
> "Use Cases" section, which could really help facilitate discussions around
> other potential solutions/approaches to a problem), the fact that the RFC
> process is still entirely voluntary on the part of the contributor(s) who
> intend to add/modify features in Geode makes me slightly hesitant to add
> extra work/complexity to it. If someone feels like it's too much effort to
> write an RFC, they may decide to skip it and go straight to PR, which for
> large/complex change sets can lead to a lot of missing context for why a
> particular approach was taken and a greater chance of only one or two
> committers actually reviewing the changes in detail rather than the larger
> community being able to weigh in on an RFC.
>
> I feel that RFCs can be a very valuable process to help determine the best
> solution to complex problems, but if there is "too much" work involved in
> creating one and nothing compelling committers to write them, we may end up
> losing out on the value they provide. Perhaps the community could agree on
> some criteria for work that would *require* an RFC, related to the
> scope/breadth of the intended changes and how many different approaches
> there might be? This would have to go hand-in-hand with a commitment from
> the community to promptly and thoroughly review RFCs, though, otherwise
> people could end up being put to the trouble of writing a comprehensive RFC
> only to have barely any actual feedback.
> ________________________________
> From: Udo Kohlmeyer <ud...@vmware.com>
> Sent: Thursday, July 9, 2020 1:18 PM
> To: geode <de...@geode.apache.org>
> Subject: [Proposal] - RFC etiquette
>
> Hi there Geode Dev's
>
> I would like to propose the following changes to the RFC process that we
> have in place at the moment.
>
> 1. All submitted RFC’s will provide a minimum 2 week review period. This
> is to allow the community to review the RFC in a reasonable timeframe. If
> we rush things, we will miss things. I’d rather have a little more time
> spent on the RFC review and getting the approach “correct” than rushing the
> RFC and then at a later point in time (either at PR review or worse
> production issue) find out that the approach was less than optimal.
> 2. Add a new section to the RFC. I would like to propose this section to
> be labelled “Use Cases”. In this section I would like all submitters to
> describe the use case that this RFC is to fulfill. This would include all
> possible combinations (success and failure) and expected outcomes of each.
>
> I hope with the additions to the RFC process and template we can better
> round out each RFC. Causing less delays later in the process and allowing
> all community members to actively participate in the review process
> regardless of technical skill level.
>
> Thoughts or comments?
>
> —Udo
>
Re: [Proposal] - RFC etiquette
Posted by Dave Barnes <db...@apache.org>.
+1
"Adding a section" (Udo's language) for Use Cases is a positive way of
encouraging RFC authors to provide that material, without saying it's an
iron-clad requirement. Exactly the right way to do it. Commenters can
request more detail when they review it.
On Thu, Jul 9, 2020 at 4:31 PM Donal Evans <do...@vmware.com> wrote:
> Udo,
>
> You're right, and I agree wholeheartedly with your proposal to give RFCs
> enough time and enough context for proper review by as many people as
> possible. Sorry if that didn't come across in my original reply.
> ________________________________
> From: Udo Kohlmeyer <ud...@vmware.com>
> Sent: Thursday, July 9, 2020 3:55 PM
> To: dev@geode.apache.org <de...@geode.apache.org>
> Subject: Re: [Proposal] - RFC etiquette
>
> Donal,
>
> You have very valid points. All of which only pertain to the “HOW” or “IF”
> an RFC should be written. This being a completely different problem to what
> I’m proposing. I’m willing to comment on any proposal that were to address
> these issues. :)
>
> This proposal is largely aimed at, if there is an existing RFC, we don’t
> try and rush it through and provide more context to reviewers to better
> comment on use case, technical approach or overall soundness of the
> proposal. If we keep aiming RFC’s at specialized technical knowledge, we
> will definitely lose reviewers who have not looked at that code in a long
> time. If the use case(s) are at least described than we can have many
> reviewers who can comment on the feature or technical approach without
> being intimate with all the inner workings of the system.
>
> I believe this approach will help with an overall better understanding of
> the systems behavior.
>
> —Udo
> On Jul 9, 2020, 1:46 PM -0700, Donal Evans <do...@vmware.com>, wrote:
> While I definitely approve of these proposals in principle (especially the
> "Use Cases" section, which could really help facilitate discussions around
> other potential solutions/approaches to a problem), the fact that the RFC
> process is still entirely voluntary on the part of the contributor(s) who
> intend to add/modify features in Geode makes me slightly hesitant to add
> extra work/complexity to it. If someone feels like it's too much effort to
> write an RFC, they may decide to skip it and go straight to PR, which for
> large/complex change sets can lead to a lot of missing context for why a
> particular approach was taken and a greater chance of only one or two
> committers actually reviewing the changes in detail rather than the larger
> community being able to weigh in on an RFC.
>
> I feel that RFCs can be a very valuable process to help determine the best
> solution to complex problems, but if there is "too much" work involved in
> creating one and nothing compelling committers to write them, we may end up
> losing out on the value they provide. Perhaps the community could agree on
> some criteria for work that would *require* an RFC, related to the
> scope/breadth of the intended changes and how many different approaches
> there might be? This would have to go hand-in-hand with a commitment from
> the community to promptly and thoroughly review RFCs, though, otherwise
> people could end up being put to the trouble of writing a comprehensive RFC
> only to have barely any actual feedback.
> ________________________________
> From: Udo Kohlmeyer <ud...@vmware.com>
> Sent: Thursday, July 9, 2020 1:18 PM
> To: geode <de...@geode.apache.org>
> Subject: [Proposal] - RFC etiquette
>
> Hi there Geode Dev's
>
> I would like to propose the following changes to the RFC process that we
> have in place at the moment.
>
> 1. All submitted RFC’s will provide a minimum 2 week review period. This
> is to allow the community to review the RFC in a reasonable timeframe. If
> we rush things, we will miss things. I’d rather have a little more time
> spent on the RFC review and getting the approach “correct” than rushing the
> RFC and then at a later point in time (either at PR review or worse
> production issue) find out that the approach was less than optimal.
> 2. Add a new section to the RFC. I would like to propose this section to
> be labelled “Use Cases”. In this section I would like all submitters to
> describe the use case that this RFC is to fulfill. This would include all
> possible combinations (success and failure) and expected outcomes of each.
>
> I hope with the additions to the RFC process and template we can better
> round out each RFC. Causing less delays later in the process and allowing
> all community members to actively participate in the review process
> regardless of technical skill level.
>
> Thoughts or comments?
>
> —Udo
>
Re: [Proposal] - RFC etiquette
Posted by Donal Evans <do...@vmware.com>.
Udo,
You're right, and I agree wholeheartedly with your proposal to give RFCs enough time and enough context for proper review by as many people as possible. Sorry if that didn't come across in my original reply.
________________________________
From: Udo Kohlmeyer <ud...@vmware.com>
Sent: Thursday, July 9, 2020 3:55 PM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [Proposal] - RFC etiquette
Donal,
You have very valid points. All of which only pertain to the “HOW” or “IF” an RFC should be written. This being a completely different problem to what I’m proposing. I’m willing to comment on any proposal that were to address these issues. :)
This proposal is largely aimed at, if there is an existing RFC, we don’t try and rush it through and provide more context to reviewers to better comment on use case, technical approach or overall soundness of the proposal. If we keep aiming RFC’s at specialized technical knowledge, we will definitely lose reviewers who have not looked at that code in a long time. If the use case(s) are at least described than we can have many reviewers who can comment on the feature or technical approach without being intimate with all the inner workings of the system.
I believe this approach will help with an overall better understanding of the systems behavior.
—Udo
On Jul 9, 2020, 1:46 PM -0700, Donal Evans <do...@vmware.com>, wrote:
While I definitely approve of these proposals in principle (especially the "Use Cases" section, which could really help facilitate discussions around other potential solutions/approaches to a problem), the fact that the RFC process is still entirely voluntary on the part of the contributor(s) who intend to add/modify features in Geode makes me slightly hesitant to add extra work/complexity to it. If someone feels like it's too much effort to write an RFC, they may decide to skip it and go straight to PR, which for large/complex change sets can lead to a lot of missing context for why a particular approach was taken and a greater chance of only one or two committers actually reviewing the changes in detail rather than the larger community being able to weigh in on an RFC.
I feel that RFCs can be a very valuable process to help determine the best solution to complex problems, but if there is "too much" work involved in creating one and nothing compelling committers to write them, we may end up losing out on the value they provide. Perhaps the community could agree on some criteria for work that would *require* an RFC, related to the scope/breadth of the intended changes and how many different approaches there might be? This would have to go hand-in-hand with a commitment from the community to promptly and thoroughly review RFCs, though, otherwise people could end up being put to the trouble of writing a comprehensive RFC only to have barely any actual feedback.
________________________________
From: Udo Kohlmeyer <ud...@vmware.com>
Sent: Thursday, July 9, 2020 1:18 PM
To: geode <de...@geode.apache.org>
Subject: [Proposal] - RFC etiquette
Hi there Geode Dev's
I would like to propose the following changes to the RFC process that we have in place at the moment.
1. All submitted RFC’s will provide a minimum 2 week review period. This is to allow the community to review the RFC in a reasonable timeframe. If we rush things, we will miss things. I’d rather have a little more time spent on the RFC review and getting the approach “correct” than rushing the RFC and then at a later point in time (either at PR review or worse production issue) find out that the approach was less than optimal.
2. Add a new section to the RFC. I would like to propose this section to be labelled “Use Cases”. In this section I would like all submitters to describe the use case that this RFC is to fulfill. This would include all possible combinations (success and failure) and expected outcomes of each.
I hope with the additions to the RFC process and template we can better round out each RFC. Causing less delays later in the process and allowing all community members to actively participate in the review process regardless of technical skill level.
Thoughts or comments?
—Udo
Re: [Proposal] - RFC etiquette
Posted by Udo Kohlmeyer <ud...@vmware.com>.
Donal,
You have very valid points. All of which only pertain to the “HOW” or “IF” an RFC should be written. This being a completely different problem to what I’m proposing. I’m willing to comment on any proposal that were to address these issues. :)
This proposal is largely aimed at, if there is an existing RFC, we don’t try and rush it through and provide more context to reviewers to better comment on use case, technical approach or overall soundness of the proposal. If we keep aiming RFC’s at specialized technical knowledge, we will definitely lose reviewers who have not looked at that code in a long time. If the use case(s) are at least described than we can have many reviewers who can comment on the feature or technical approach without being intimate with all the inner workings of the system.
I believe this approach will help with an overall better understanding of the systems behavior.
—Udo
On Jul 9, 2020, 1:46 PM -0700, Donal Evans <do...@vmware.com>, wrote:
While I definitely approve of these proposals in principle (especially the "Use Cases" section, which could really help facilitate discussions around other potential solutions/approaches to a problem), the fact that the RFC process is still entirely voluntary on the part of the contributor(s) who intend to add/modify features in Geode makes me slightly hesitant to add extra work/complexity to it. If someone feels like it's too much effort to write an RFC, they may decide to skip it and go straight to PR, which for large/complex change sets can lead to a lot of missing context for why a particular approach was taken and a greater chance of only one or two committers actually reviewing the changes in detail rather than the larger community being able to weigh in on an RFC.
I feel that RFCs can be a very valuable process to help determine the best solution to complex problems, but if there is "too much" work involved in creating one and nothing compelling committers to write them, we may end up losing out on the value they provide. Perhaps the community could agree on some criteria for work that would *require* an RFC, related to the scope/breadth of the intended changes and how many different approaches there might be? This would have to go hand-in-hand with a commitment from the community to promptly and thoroughly review RFCs, though, otherwise people could end up being put to the trouble of writing a comprehensive RFC only to have barely any actual feedback.
________________________________
From: Udo Kohlmeyer <ud...@vmware.com>
Sent: Thursday, July 9, 2020 1:18 PM
To: geode <de...@geode.apache.org>
Subject: [Proposal] - RFC etiquette
Hi there Geode Dev's
I would like to propose the following changes to the RFC process that we have in place at the moment.
1. All submitted RFC’s will provide a minimum 2 week review period. This is to allow the community to review the RFC in a reasonable timeframe. If we rush things, we will miss things. I’d rather have a little more time spent on the RFC review and getting the approach “correct” than rushing the RFC and then at a later point in time (either at PR review or worse production issue) find out that the approach was less than optimal.
2. Add a new section to the RFC. I would like to propose this section to be labelled “Use Cases”. In this section I would like all submitters to describe the use case that this RFC is to fulfill. This would include all possible combinations (success and failure) and expected outcomes of each.
I hope with the additions to the RFC process and template we can better round out each RFC. Causing less delays later in the process and allowing all community members to actively participate in the review process regardless of technical skill level.
Thoughts or comments?
—Udo
Re: [Proposal] - RFC etiquette
Posted by Donal Evans <do...@vmware.com>.
While I definitely approve of these proposals in principle (especially the "Use Cases" section, which could really help facilitate discussions around other potential solutions/approaches to a problem), the fact that the RFC process is still entirely voluntary on the part of the contributor(s) who intend to add/modify features in Geode makes me slightly hesitant to add extra work/complexity to it. If someone feels like it's too much effort to write an RFC, they may decide to skip it and go straight to PR, which for large/complex change sets can lead to a lot of missing context for why a particular approach was taken and a greater chance of only one or two committers actually reviewing the changes in detail rather than the larger community being able to weigh in on an RFC.
I feel that RFCs can be a very valuable process to help determine the best solution to complex problems, but if there is "too much" work involved in creating one and nothing compelling committers to write them, we may end up losing out on the value they provide. Perhaps the community could agree on some criteria for work that would *require* an RFC, related to the scope/breadth of the intended changes and how many different approaches there might be? This would have to go hand-in-hand with a commitment from the community to promptly and thoroughly review RFCs, though, otherwise people could end up being put to the trouble of writing a comprehensive RFC only to have barely any actual feedback.
________________________________
From: Udo Kohlmeyer <ud...@vmware.com>
Sent: Thursday, July 9, 2020 1:18 PM
To: geode <de...@geode.apache.org>
Subject: [Proposal] - RFC etiquette
Hi there Geode Dev's
I would like to propose the following changes to the RFC process that we have in place at the moment.
1. All submitted RFC’s will provide a minimum 2 week review period. This is to allow the community to review the RFC in a reasonable timeframe. If we rush things, we will miss things. I’d rather have a little more time spent on the RFC review and getting the approach “correct” than rushing the RFC and then at a later point in time (either at PR review or worse production issue) find out that the approach was less than optimal.
2. Add a new section to the RFC. I would like to propose this section to be labelled “Use Cases”. In this section I would like all submitters to describe the use case that this RFC is to fulfill. This would include all possible combinations (success and failure) and expected outcomes of each.
I hope with the additions to the RFC process and template we can better round out each RFC. Causing less delays later in the process and allowing all community members to actively participate in the review process regardless of technical skill level.
Thoughts or comments?
—Udo
Re: [Proposal] - RFC etiquette
Posted by John Blum <jb...@vmware.com>.
+1
________________________________
From: Patrick Johnson <jp...@vmware.com>
Sent: Thursday, July 9, 2020 1:31 PM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [Proposal] - RFC etiquette
+1
> On Jul 9, 2020, at 1:18 PM, Udo Kohlmeyer <ud...@vmware.com> wrote:
>
> Hi there Geode Dev's
>
> I would like to propose the following changes to the RFC process that we have in place at the moment.
>
> 1. All submitted RFC’s will provide a minimum 2 week review period. This is to allow the community to review the RFC in a reasonable timeframe. If we rush things, we will miss things. I’d rather have a little more time spent on the RFC review and getting the approach “correct” than rushing the RFC and then at a later point in time (either at PR review or worse production issue) find out that the approach was less than optimal.
> 2. Add a new section to the RFC. I would like to propose this section to be labelled “Use Cases”. In this section I would like all submitters to describe the use case that this RFC is to fulfill. This would include all possible combinations (success and failure) and expected outcomes of each.
>
> I hope with the additions to the RFC process and template we can better round out each RFC. Causing less delays later in the process and allowing all community members to actively participate in the review process regardless of technical skill level.
>
> Thoughts or comments?
>
> —Udo
Re: [Proposal] - RFC etiquette
Posted by Patrick Johnson <jp...@vmware.com>.
+1
> On Jul 9, 2020, at 1:18 PM, Udo Kohlmeyer <ud...@vmware.com> wrote:
>
> Hi there Geode Dev's
>
> I would like to propose the following changes to the RFC process that we have in place at the moment.
>
> 1. All submitted RFC’s will provide a minimum 2 week review period. This is to allow the community to review the RFC in a reasonable timeframe. If we rush things, we will miss things. I’d rather have a little more time spent on the RFC review and getting the approach “correct” than rushing the RFC and then at a later point in time (either at PR review or worse production issue) find out that the approach was less than optimal.
> 2. Add a new section to the RFC. I would like to propose this section to be labelled “Use Cases”. In this section I would like all submitters to describe the use case that this RFC is to fulfill. This would include all possible combinations (success and failure) and expected outcomes of each.
>
> I hope with the additions to the RFC process and template we can better round out each RFC. Causing less delays later in the process and allowing all community members to actively participate in the review process regardless of technical skill level.
>
> Thoughts or comments?
>
> —Udo