[chef-dev] Scope of RFC process (was: RFC: Template Verification)

[Daniel DeLeo < >]

On Thursday, July 31, 2014 at 8:36 AM, Mike wrote:  
> > ... “small, backwards compatible features” ...
>  
>  
> Isn't one of the goals of RFC procedure to determine the small-ness of the 
> given feature?  
> I think it might be easy to introduce many small, backwards compat features 
> that eventually become hard to change if the overall vision doesn't map to 
> where the project is desiring to go.
>  
> Filling out RFCs for features, not bugfixes, seems reasonable to me, as 
> they widen the visibility and expose the feature to discourse.
>  
> -M
What I fear about this is that while nearly all process starts out 
well-intentioned, if it gets in the way of progress, then you end up with 
negative outcomes.

For example, suppose I want to add a new knife command, like `knife ssl 
check`. It’s pretty straightforward, but if I have to deal with a bunch of 
process before I can implement it, then maybe I just release it as a plugin 
as a way of working around the process. Now anyone who needs this 
functionality also needs to learn that it exists as a plugin and install it 
before they can use it. For users who are less “plugged in” to the community 
(or maybe were just on vacation when it was announced), they might never find 
out about it at all.

As another example, suppose a person who’s not heavily involved in the chef 
community contributes a patch to add a small, straightforward feature. 
Instead of simply merging it, we’d have to tell that person to write an RFC, 
sign up for the chef-dev list, mail the list with their proposal, monitor any 
replies for at least a week, monitor replies to their RFC on GitHub for at 
least a week, and then finally we could merge the patch. Lots of people would 
walk away at that point.

The thing I think that’s important here is that, while the RFC process (and 
the governance policy we’re working on) will empower people who are very 
engaged with Chef and the community, we still have a responsibility to do the 
best we can for people who are less engaged. I think it’s true for all of us 
that we simply don’t have time to be fully engaged with every open source 
software project that has a huge impact on our day to day lives (personal 
example: I’m not on any ruby mailing lists or IRC channels, though I write a 
ton of ruby developing chef-client).

--  
Daniel DeLeo