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

[Noah Kantrowitz < >]

As with most such things, it is easy to say where some extremes are, but the 
devil is in the gray area. In general, if something is a big enough feature 
that it would be a bullet point in the release announcement, it should 
probably be discussed (via RFC or otherwise).

--Noah

On Jul 31, 2014, at 11:42 AM, Adam Jacob 
<
 >
 wrote:

> This is an easy case of no need to make a rule before the problem happens. 
> :)
> 
> I would say its on the maintainers to use good judgement about when we 
> think an RFC is needed. As we get more clarity on the maintenance process, 
> folks who are interested can follow multiple streams easily.
> 
> Adam
> 
> 
> On Thu, Jul 31, 2014 at 11:32 AM, Mike 
> <
 >
>  wrote:
> I'll agree with about 99% of Dan's comments, especially about the barrier 
> to entry, as any non-Opscode employee found out with the CLA process, with 
> one caveat:
> 
> I think it is important to know where to draw the line - if by adding a 
> feature that promotes functionality that will later need to be rethought, 
> refactored, isn't it better to catch that before it makes it in?
> -M
> 
> 
> On Thu, Jul 31, 2014 at 12:05 PM, Daniel DeLeo 
> <
 >
>  wrote:
> 
> 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
> 
> 
>

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail