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