[chef-dev] Re: Re: Re: Re: Nodejs community CK mess

[Noah Kantrowitz < >]

-Inf, I wouldn't want Chef Inc having any formal control over governance of 
my code, nor is my code a democracy, and I would like my stuff to be listed 
as existing. Supermarket is a sharing site, it should not have strong 
opinions like this.

--Noah

On Jul 18, 2014, at 11:44 AM, Cameron Cope 
<
 >
 wrote:

> What do you think about making that governance model a requirement for 
> listing cookbooks on the official Supermarket site? It could help reduce 
> confusion in the community if there were a 1:1:1 relationship of 
> supermarket:namespace:government.
> 
> -Cam
> 
> On Fri, Jul 18, 2014 at 2:34 PM, Adam Jacob 
> <
 >
>  wrote:
> We're actively in the process of deciding how we maintain things for Chef 
> proper. Once that is done, I would propose we could look at doing something 
> that basically allows people to "opt-in" to that governance model - where, 
> for example, the author of a community cookbook who intends for it to be 
> "canonical" can choose to adopt the "normal" Chef governance model, and 
> hence have mechanisms for dealing with these cases.
> 
> We could then mark cookbooks that have opted in. While it wouldn't make any 
> statements about quality, it would tell you precisely which ones have a 
> stricter central governance model.
> 
> Adam
> 
> 
> On Fri, Jul 18, 2014 at 11:22 AM, Cameron Cope 
> <
 >
>  wrote:
> I've heard the statement several times that Chef Software doesn't want to 
> act like a dictator, but it seems tome that the community wants some sort 
> of leadership and organization. I agree that looking at other examples for 
> namespacing might help, but don't just look at the technical details of 
> those systems, research how OSS communities organize and govern themselves. 
> I highly recommend looking at governance in Debian, Ubuntu, and the Apache 
> Foundation. As the corporate backer of Chef, I think it's perfectly 
> reasonable for you guys to decide what your governance model is and how 
> much control your have.
> 
> http://oss-watch.ac.uk/resources/governancemodels
> https://www.debian.org/devel/constitution
> http://www.ubuntu.com/about/about-ubuntu/governance
> http://www.apache.org/foundation/how-it-works.html
> 
> -Cam
> 
> On Fri, Jul 18, 2014 at 7:52 AM, Christopher Webber 
> <
 >
>  wrote:
> I think this is a great example of something we need to address…
> 
> With that said, I have more questions than answers.
> 
> The first thing I would do is look to how other communities and package 
> repositories handle this issue. I am on vacation right now and won’t have a 
> chance to do the research myself until I get back, but I really would love 
> to see a good example of how this is handled elsewhere. How do CPAN, NPM, 
> RubyGems, etc handle this?
> 
> On a technical level, I think there are a lot more questions that have to 
> be answered. Some of them that come to mind would be:
> 
> If we transfer the name to someone else:
> - What requirement do they have to maintain legacy code?
> - What is the expectation around breaking or not breaking the API the 
> cookbook provides, especially if SemVer isn’t in use?
> - Does the license on the old cookbook allow for it to even be maintained?
> 
> Since we have talked a lot about namespacing, how would that change this 
> equation? Does it actually solve the problem we are trying to solve? Has it 
> played out that way in other communities that use namespacing like Docker 
> or the Puppet Forge?
> 
> The biggest problem in all of this… Who gets to be the decider? How do we 
> do this in a fair manner? It is easy to look at code and have the attitude 
> this sucks, mine is better, but it is much harder to have to explain to 
> someone that this person or group has decided to take a thing away from 
> them. My personal fear is that we discount the people side of this 
> situation. People and feelings are a wicked hard problem set and there 
> really is no good answer. But, as we move forward with any discussion 
> around this, I would love to hear how people think we should handle this 
> part of the equation.
> 
> For me, the biggest thing I don’t want to see is Chef Software become the 
> decider and ruler. I want to see it be the community that comes together 
> around a set of values and a process for governance. While I think it is 
> important that Chef Software have a seat at the table and that they take on 
> the responsibility of running the site, I don’t think Chef Software should 
> have the end all say in how we govern things.
> 
> Just my 2 cents.
> 
> — cwebber
> 
> On Jul 18, 2014, at 4:22 AM, 
> <
 >
>  
> <
 >
>  wrote:
> 
> > Ohai everyone!
> >
> > We wanted to report an academic example of cookbook governance issues. 
> > Hoping
> > this will further the subject.
> >
> > As everyone know, nodejs is really popular and many of you want to deploy 
> > it
> > for production (maybe with npm packages too).
> > For now a simple search on supermarket give us:
> >    - node
> >    - nodejs
> >    - npm
> >    - node-windows
> >
> > And we may lack some.
> > Moreover, none of them have enough quality and tests for a real production
> > proof system.
> >
> > With our experience, we're trying to rebuild a new cookbook with 
> > experience of
> > each other.
> > Discussion begins here: https://github.com/balbeko/chef-npm/pull/26
> > To federate all this dev, we created a collaborative organization 
> > "REDGUIDE"
> > (https://github.com/redguide) and started fusion and improvement from 
> > existing
> > work.
> >
> > This cookbook (available here: https://github.com/redguide/nodejs ;) is now
> > really good regarding to current chef practices. It also started to be 
> > widely
> > used and known by the community.
> >
> > Final step: publishing it...
> > Here come problems: https://github.com/redguide/nodejs/issues/9
> >
> > TL;DR : Previous maintainer want to keep control over cookbook and to 
> > keep it
> > under his name despite the fact that it is no longer open, active and
> > responsive on this CK
> > (https://github.com/mdxp/nodejs-cookbook/issues?state=open).
> >
> > This decision is really painful for everyone, it blocks all good things 
> > done by
> > community (and block application_nodejs to use it as "depends" for 
> > example).
> >
> > NEXT:
> >    - For this project:
> >       - Press nodejs maintainer to accept the merge and release his 
> > control
> > over community repo (community work belong to the community)
> >       - Creating a yet-another-nodejs cookbook? (or better nodejs-ii, as 
> > we
> > can see for timezone and timezone-ii)
> >       - Destitute maintainer of his role on supermarket (never a good 
> > news to
> > do this)
> >    - For chef:
> >       We really have to manage this kind of case in supermarket. The main
> > risk is that  people/company  who are using community cookbooks  stop 
> > trusting
> > community work anymore, and start writing as much fork/copy (either 
> > public or
> > private) of the same work. Community work would be severely affected by 
> > this.
> >       This is not the way we think Chef should be.
> >
> > Our proposition (but must be debated):
> >    - When someone create a new cookbook on supermarket, a new github repo 
> > is
> > created (like https://github.com/jenkinsci/ do).
> >    - It prevent git erase / modification.
> >    - This repo became the new "central point" for community issues /
> > contributions as it doesn't belong to someone in particular, governancy 
> > can be
> > edicted by getchef/community.
> >
> > We also can provide test platform (for TK for example) easily.
> 
> 
> 
>

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail