Supermarket Governance - chef-boneyard/chef-summit-2014 GitHub Wiki

Supermarket Governance

Friday, Leschi, 1300

Namespacing

  • Naming is complicated
  • Looking to seeing what comes out of NPM forge around namespacing
  • Feels like may be premature to discuss

Governance

  • Currently a small group of people that have the ability to modify community supermarket

    • How should this be managed
    • Should there be other people outside of Chef community have the 'admin bit'
    • When is it appropriate to take down a cookbook
    • How do you handle the 'I uploaded a broken cookbook'
    • How do you deal with 'abusive cookbooks', 'accidental upload of sensitive data' 'abandonment' squatting
    • Can remove a version
    • Should have self-service delete capability
    • What about governing on 'quality characteristics'

    What happens when someone can delete a build?

    • If someone has downloaded the cookbook before it was built, they won't know why it was deleted
    • Rubygems has capability to yank a gem, can't upload with the same version
    • Yank, fix, deploy new buld, and document

Summary: We want the ability to yank a cookbook version, and we're OK that it may break some people

Is there an organizational capability to push/pull cookbooks? Yes, though the use of shared credentials.

Goal is to write RFC around Governance

Abuse

  • Should be a way to flag abuse (through UI element)
  • Should have clear definition of what abuse is
  • Technical definition of 'abuse' - Does it do what's described
  • Who are the admins of supermarket? Who are the Moderators?
    • Mirror the Chef Maintenance Policy?

    • Chef maintenance policy, nominated lieutenant, volunteer as a contributor, have to get approved by majority of contributors

    • Policy should be public, transparent

    • Parallel the example of User Generated Content process where users upload content, it goes into content moderation queue, and gets approved or rejected

    • Do we want a moderated / curated (private supermakert) approval process

      • If so, does it slow people down. Is this an appropriate place to slow people down?
      • Increased barrier to entry?
    • Determine quality by asking if it has test kitchen setup, has it passed tests recently, show food critic output, what test suites does it have

Abandonment

  • What is the impact of abandonment, you can always fork it and republish under a new name

    • If someone has a replacement with actual code, should the moderators be able to decide
    • Jenkins plugins, sometimes people comment or redirect to other plugins that are better
  • Abandonment vs squatting

    • I haven't done anything with the cookbook for a while

    • I've decided not to maintain things anymore

    • I got the cookbook name but haven't done anything with it

    • Feature requests are no longer getting committed, but bug fixes are

      • have a way of flagging intention of working on work items
    • Should it be a guideline that source code be available and linked in the artifact

    • In the EULA there is redistribution rights given to Chef, however, license doesn't have to be open source

      • Cisco is a good example, there is proprietary bits included
    • Death and succession

    • Pypi had a dustup, and semi official policy

      • Must have an affirmative response from the maintainer
      • Someone who goes on vacation for 3 months doesn't mean it abandoned
    • Current development state flag? - Looking for maintainers?

    • What are the possible responses to abandonment

      • Do nothing
      • Nuke it
      • Nominate for 'stagnation'
      • Request review for for abandonment, is there going to be public notice of review, transparency??
      • How do you notify maintainers
    • How to identify 'popularity' of cookbook - downloads is not sufficient

Action items

We're going to punt on abandonment, going to address death issue, delete issue (self service), abuse issue, and secrets issue.

Decided not to discuss aspects of 'quality' though seemed that this may be an important thing to discuss further... deep rabbit hole.

Michael Weinberg - [email protected] volunteers to help write RFC

⚠️ **GitHub.com Fallback** ⚠️