This is an easy case of no need to make a rule before the problem
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.
On Thu, Jul 31, 2014 at 11:32 AM, Mike email@example.com 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?
On Thu, Jul 31, 2014 at 12:05 PM, Daniel DeLeo firstname.lastname@example.org
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.
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
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).