I think “small, backwards compatible features” can just be a pull request. In general my thoughts are:
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?
* 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
Archive powered by MHonArc 2.6.16.