RFC: Template Verification


#1

Ohai Chefs,

I’ve posted a small RFC here:

about a feature I’d like to add to Chef.

This RFC is also interesting to me in terms of the emerging chef-rfc
process. In the past, I would have proposed a feature this small
simply as a pull request with the code already written. For small,
backwards compatible features, is that preferable over an RFC?

Cheers,

Steven


#2

For backwards compatible, I’d support whichever is easiest to convey the idea.

Also +1 to verification!


~j

On Jul 31, 2014, at 11:57, Steven Danna steve@opscode.com wrote:

Ohai Chefs,

I’ve posted a small RFC here:

https://github.com/opscode/chef-rfc/pull/38

about a feature I’d like to add to Chef.

This RFC is also interesting to me in terms of the emerging chef-rfc
process. In the past, I would have proposed a feature this small
simply as a pull request with the code already written. For small,
backwards compatible features, is that preferable over an RFC?

Cheers,

Steven


#3

On Thursday, July 31, 2014 at 4:57 AM, Steven Danna wrote:

Ohai Chefs,

I’ve posted a small RFC here:

https://github.com/opscode/chef-rfc/pull/38

about a feature I’d like to add to Chef.

This RFC is also interesting to me in terms of the emerging chef-rfc
process. In the past, I would have proposed a feature this small
simply as a pull request with the code already written. For small,
backwards compatible features, is that preferable over an RFC?

I think “small, backwards compatible features” can just be a pull request. In general my thoughts are:

  • Anything breaking cookbook DSL compatibility should be an RFC
  • For changes to chef-server, we should err on the side of using the RFC process, because there are two implementations maintained by Chef Software and at least one maintained by a third party. Optional features, like node history reporting, which are implemented by Chef Software as paid add-ons are a probable exception (with the stipulation being that chef-client works correctly in the absence of these features).
  • Aside from the above, size/scope should be the determining factor. If unsure, you can ask on the mailing list.
  • The RFC process shouldn’t be used as a substitute for contributing code. Chef Software is going to prioritize its engineers’ time based on what makes business sense. Even the most excellent ideas are not guaranteed to be prioritized.

Cheers,

Steven

Maybe we should write this up as a retroactive “rfc zero” that goes in the README of chef-rfc?


Daniel DeLeo


#4

… “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

On Thu, Jul 31, 2014 at 11:27 AM, Daniel DeLeo dan@kallistec.com wrote:

On Thursday, July 31, 2014 at 4:57 AM, Steven Danna wrote:

Ohai Chefs,

I’ve posted a small RFC here:

https://github.com/opscode/chef-rfc/pull/38

about a feature I’d like to add to Chef.

This RFC is also interesting to me in terms of the emerging chef-rfc
process. In the past, I would have proposed a feature this small
simply as a pull request with the code already written. For small,
backwards compatible features, is that preferable over an RFC?

I think “small, backwards compatible features” can just be a pull request.
In general my thoughts are:

  • Anything breaking cookbook DSL compatibility should be an RFC
  • For changes to chef-server, we should err on the side of using the RFC
    process, because there are two implementations maintained by Chef Software
    and at least one maintained by a third party. Optional features, like node
    history reporting, which are implemented by Chef Software as paid add-ons
    are a probable exception (with the stipulation being that chef-client works
    correctly in the absence of these features).
  • Aside from the above, size/scope should be the determining factor. If
    unsure, you can ask on the mailing list.
  • The RFC process shouldn’t be used as a substitute for contributing code.
    Chef Software is going to prioritize its engineers’ time based on what
    makes business sense. Even the most excellent ideas are not guaranteed to
    be prioritized.

Cheers,

Steven

Maybe we should write this up as a retroactive “rfc zero” that goes in the
README of chef-rfc?


Daniel DeLeo


#5

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


#6

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 dan@kallistec.com 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


#7

This is an easy case of no need to make a rule before the problem happens.
:slight_smile:

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 miketheman@gmail.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?
-M

On Thu, Jul 31, 2014 at 12:05 PM, Daniel DeLeo dan@kallistec.com 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


#8

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 adam@getchef.com wrote:

This is an easy case of no need to make a rule before the problem happens. :slight_smile:

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 miketheman@gmail.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?
-M

On Thu, Jul 31, 2014 at 12:05 PM, Daniel DeLeo dan@kallistec.com 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


#9

The rule we’ve been trying to follow to have a bullet point in the release
announcement is if the change has compatibility implications or if it
requires a documentation change.

I don’t think the same applies for RFCs. E.g. we probably don’t want to
have an RFC to add a new attribute to the service resource.

I’m with Adam on we should leave it to the maintainers to judge if an RFC
is needed or not.

– Serdar

On Thu, Jul 31, 2014 at 12:20 PM, Noah Kantrowitz noah@coderanger.net
wrote:

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 adam@getchef.com wrote:

This is an easy case of no need to make a rule before the problem
happens. :slight_smile:

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 miketheman@gmail.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?
-M

On Thu, Jul 31, 2014 at 12:05 PM, Daniel DeLeo dan@kallistec.com
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