Nodejs community cookbooks governance


#1

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.


Devops & Release Manager @Photobox
Barthélemy Vessemont - bvessemont@gmail.com