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
