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
>
>
>
Archive powered by MHonArc 2.6.16.