+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" <dbar...@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 <doev...@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 <u...@vmware.com>
> Sent: Thursday, July 9, 2020 3:55 PM
> To: dev@geode.apache.org <dev@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 <doev...@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 <u...@vmware.com>
> Sent: Thursday, July 9, 2020 1:18 PM
> To: geode <dev@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
>
