Thursday, Feb 11, 2016 marked the first meeting of the Chef Board of Governance (CBGB) in San Francisco. In attendance were 11 of the members of the board, as well as Nathen Harvey and Thom May from Chef Software to observe and advise as the leads of the community teams at Chef Software.
Project Lead
Adam Jacob, Chef
Users/Contributors
Corporate Contributors
Lieutenants
Mark Ayers, a Corporate Contributor from Nordstrom was unable to attend.
As the first meeting, we defined what the board would be and do. We worked out four main responsibilities for the board:
The board will meet four times a year, twice in person and twice online. After each in-person meeting we will produce a report similar to this. The tasks for the board will be reviewed each time, but these are a starting point.
We used the Mission, Vision, and Values process to work out what we feel is the overall mission statement for the Chef community as a whole. The mission states the long-term (10+ years) goals of the community, while the vision is a short-term (6-12 months) priority. Our values are the things we feel are most important about our community.
Mission
The Chef community exists to create a welcoming, transformative, and transparent environment that enriches the daily life of Chef users.
Vision
Chef community members feel safe, supported, and effective participating in and contributing to the Chef ecosystem.
Values
The first major topic of discussion was about major RFCs and a lack of overall “plot” in some recent cases of related RFCs and pull requests. We would like to re-affirm the ability of any Chef maintainer to request a comprehensive “why” when it seems like there is some deeper reason for a change that isn’t clear. If the component lieutenant can’t answer the question, they should ask the RFC or pull request author to document it. Care should be take to avoid bias towards Chef Software employees, they should be held to the same standard as all other contributors when it comes to large-scale changes.
In cases where a change will touch a lot of things, it is encouraged that the overall vision be laid out in an epic-level RFC with links to the sub-RFCs as they are created.
Additionally RFCs should make special note of expected impact to downstream projects beyond Chef itself. This includes major Chef ecosystem tools, projects, and integrations.
The RFC Template in RFC000 should be updated with an Expected Impact to Chef Ecosystem tools, e.g. ChefSpec.
After that, we discussed the current state of the Chef maintenance policy (RFC 30). Overall we are happy with the implementation of the policy for Chef, and the other projects that have joined under it. We would like to approach the maintainers of some major ecosystem projects to see if it would be beneficial to them to be part of the same maintenance structure.
Finally we would like to re-state that all maintainers are expected to uphold the Chef Community Guidelines.
The first community health discussion was about what it means for something to be “supported” in the Chef ecosystem. We would like to highlight the existence of RFC 19 as a list of workflows which will always be supported with all tools under the Chef maintenance policy. As mentioned above we would like to expand the maintenance policy to include more Chef ecosystem projects.
We also talked about what expectations should be in place as more projects join under the maintenance policy. At a minimum any project should:
We discussed concerns about a dilution in the Chef community by having too many places to congregate as well as some of the majors places being difficult for new users to access. We would like to create new microsite (something like https://community.chef.io/) to direct users to the best places to find help as new users or existing community members struggling with Chef. Some of the less used gathering places, such as the subreddit or LinkedIn group, should include a link to this site to try and avoid user frustration at slow responses. The board would like to recommend that the community investigate setting up a Slack team to (eventually) replace our usage of Freenode IRC for community chat and near-real-time support. This is likely to be a contentious transition so it will be discussed in an RFC to be filed later, but the board feels this is an important step towards ensuring our community continues to be accessible and welcoming given the historic UX difficulties with IRC.
We would like to encourage the Chef maintainers to work towards formalizing a distinction between public and private internals. Private methods in Chef should be marked private so external tools which use Chef internals can avoid those methods.
We would also like to strongly encourage the Chef maintainers to move forward with the implementation of RFC 31 so we can once and for all stop arguing about chef-solo. Finally we would like to request that the ChefDK release team pursue publishing builds to the stable channel on Omnitruck.
We the board do not see a compelling reason to move forward with a Chef 13 release at this time.
We would like to see a monthly cadence for feature releases of Chef and would encourage other Chef ecosystem projects to explore if they can use a similar release cycle.
The next CBGB meeting will be at ChefConf in July. If anyone has questions or thoughts for the board, you can reach us at cbgb@chef.io.