[chef] Re: Re: Re: Re: [chef-dev] Ownership Changes of Chef Cookbooks Revisited

[Lamont Granquist < >]

I would really like to see Chef not be the SPOF for cookbook sharing and governance.  I would love to see someone aggressively fork the community site and implement their own code quality standards, supported features and governance.  Because as long as we think we're trying to produce the one apache cookbook that works on every RHEL, Debian, Ubuntu, Gentoo, Arch, Solaris and AIX distro for the past 10 years and supports binary and source installation, etc we're going to produce a mess which satisfies almost nobody.  The models of rubygems and CPAN and other library sites for languages are a really bad metaphor for this domain because we don't just have the problem of running on a few different versions of a language, but running on a huge matrix of different O/Ses and distros and all the ways that sysadmins like to maintain their servers.  There will never be the OneTrueWayToInstallApache.

It would also be good to see better competition in the 'marketplace' for cookbook governance.  I'd love to see us be able to be lazy and just steal good ideas that other people had implemented and had turned out to be successful (and also learn from the failures that happen).  Ideally Chef, the company, just gets out of the business of managing cookbooks entirely and we can focus on building the software behind it all.  I don't think that happens unless you have a robust, self-supporting community, though, and right now it feels too much like the Chef community is just looking entirely at the company to provide all the leadership here.  I don't think that's a good thing.

And when people start talking about "enforcement of community standards" when there's just one game in town, my inner anarchist gets very upset.  I'd prefer to see different communities, and if one of them has a complete internal political meltdown over moderation and governance then you can fork it all and patch the politics.

On 5/23/14, 6:14 PM, Sean OMeara wrote:

" type="cite">

Hi Ryan!

We've been thinking about this quite a bit lately. With Supermarket on its way, this is the perfect time to rekindle the conversation.

To answer you first question, we retain a commit bit on cookbooks which were previously maintained by Chef, but trust the maintainers to do what they think is best. Currently, issues with maintainer-ship are handled on an individual case by case basis.

Like Julian mentioned, we're looking at other projects (Arch Linux, Perl) for examples of governance policies. The key is to be super clear about exactly what issues such a policy is intended to solve, and not to discourage or alienate people when enforcing such policies. Issues like how to handle abandoned projects clearly need to be addressed.

One of the exciting things about Supermarket shipping, is we'll finally have a hackable community site. Instrumenting that to provide visibility into usage patterns is going to allow us to make better decisions. It also gives us the freedom to start tinkering around with things like name spacing.

-s

On Fri, May 23, 2014 at 9:08 PM, Christopher Webber < " target="_blank"> > wrote:

So first off, thank you for the email Ryan. These issues are super important and I want to make sure we address them in a thoughtful and open manner.

So a couple of things stand out to me:

1) At this point, software quality isn’t really a solved problem. We have great tools like ChefSpec, Test Kitchen, Rubocop and Foodcritic to give us information about the quality of our code but they are not 100%. With that said, we should probably work towards a community standard of what constitutes a quality cookbook, if only to give those of us writing cookbooks a yardstick to measure ourselves by.

2) I worry about the idea of “enforcing” high quality. Things like setting standards for unresponsiveness and cookbook abandonment make a ton of sense to me, but the problem with enforcing around quality is that it becomes a very dangerous path and I think I would rather see us get some of the other aspects down before we even begin that process.

3) There is another idea that we really haven’t discussed around ownership. I don’t have enough background to know the actual agreements around the cookbooks that the community has taken on, but it doesn’t seem like the cool thing to just take back a cookbook. Additionally, I worry about the precedent that doing so would set as the associated implications of doing such a thing. I think about it this way… Just because a sysadmin has the ability to read all the email on a system doesn’t mean it is right of them to do so. There are usually organizational policies and guidelines that govern when it is acceptable to do so. If we start down a path of governance and defining rules around these things, this would be a place I would like to see us address.

I really would like to hear what the community thinks about all of the things presented. More than anything, I would like to know if working towards a governance policy or set of guidelines is something the community wants undertake. I know we (Chef Software, Inc.) would love to be a part of facilitating that discussion and are key stakeholders, but I don’t think any of us want to go down the Governance path if there isn’t support from the greater community to do so.

Thanks!

— cwebber

On May 23, 2014, at 4:56 PM, Julian C. Dunn < "> > wrote:

> Hey Ryan,
>
> I'm actually gonna shift this thread to chef@ so that it gets broader
> visibility.
>
> I've been meaning to address some of the points here since we had the
> Cookbook Governance BoF at ChefConf (and I have been remiss in not
> posting a summary from that). I have a short deck that summarized how
> I set up the conversation at the BoF:
> http://www.slideshare.net/JulianDunn/chef-cookbook-governance-bof-at-chefconf
>
> What we heard from folks there is that the community wants Chef
> (Software, Inc.) to be more prescriptive about managing the namespaces
> on the community site. In other words, folks who were at the BoF
> wouldn't mind if we set some standards for evicting unresponsive
> maintainers from those namespaces, and/or transferring ownership to
> others who want to take over cookbooks -- provided, of course, that we
> have made a good faith effort to contact maintainers & encourage them
> to do their duty.
>
> I'd like to hear from others who weren't at the BoF if they also feel
> this way. If you do, then I think we (Chef Software, Inc.) should work
> with the community to develop some of these rules, and then enforce
> them, to the extent that 'enforce' means 'be the broker of last resort
> in case of dispute or cookbook abandonment'.
>
> I've also asked Chris Webber, our community software developer, to
> weigh in on this thread. He has some thoughts that may be pertinent.
>
> - Julian
>
> On Fri, May 23, 2014 at 4:58 PM, Ryan Hass < "> > wrote:
>> A little over six months have gone by since many of the cookbooks were
>> handed off to various community maintainers. Now seems like a good time
>> to continue this discussion with wisdom at hand; I am sure many others,
>> like myself may have questions and surely have ideas on how to improve.
>>
>> Many of the cookbook maintainers have done an outstanding job of working
>> with the community, resolving issues, and accepting and mentoring
>> changes. Unfortunately, there are a few which have not met the quality
>> standards which preceded their maintainer-ship. Having said this, I
>> would like to discuss the Chef governance policy with regards to
>> maintainers whom have been unable to fulfill their duties, and the
>> process of ensuring these cookbooks continue to have high quality going
>> forward.
>>
>> Some questions I have are:
>>
>> * What is the current governance of cookbooks which were previously
>> maintained by Chef (Opscode)?
>>
>> * How can the community get involved in this governance process to
>> ensure high quality standards persist for said cookbooks?
>>
>> Please do not hesitate to share your questions or thoughts on the
>> subject of the cookbooks which were handed off. As mentioned, I am sure
>> there are many others with related questions and ideas on the topic.
>>
>> -Ryan H.
>> This electronic message contains information which may be confidential or privileged. The information is intended for the use of the individual or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify us by e-mail at ( "> ) immediately.
>>
>
>
>
> --
> [ Julian C. Dunn < "> >          * Sorry, I'm    ]
> [ WWW: http://www.aquezada.com/staff/julian    * only Web 1.0  ]
> [ gopher://sdf.org/1/users/keymaker/           * compliant!    ]
> [ PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9       ]

" type="cite">