+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 >
