----
Chef Board of Governance Meeting
// Chef Blog
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.
Members in attendance
Project LeadAdam Jacob, Chef
Users/Contributors
- Ranjib Dey
- Doug Ireton
- Noah Kantrowitz
- Charity Majors
- Etsy – Katherine Daniels
- Facebook – Phil Dibowitz
- PagerDuty – Evan Gilman
- Jon Cowie
- Joshua Timberman
- Seth Vargo
The Role of the CBGB
As the first meeting, we defined what the board would be and do. We worked out four main responsibilities for the board:- Define a mission statement and core values for the Chef community.
- Review core processes of the Chef ecosystem and suggest improvements.
- Monitor the health of the Chef community.
- Provide recommendations to Chef's maintainers about the technical direction of the project.
Mission Statement and Core Values
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
- Welcoming
- Inclusive
- Safe
- Diverse
- Transformative
- Transparent
- Helpful
- Delightful
- Pragmatic
Core Processes
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.
Health of the Chef Community
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:
- Have an OSI-approved license (Apache 2.0 preferred but not required)
- Accept the Chef Community Guidelines for its own community
- Have a maintainer willing to act as a lieutenant
- Have at least two maintainers with the ability to create a new release
- Add a link back to the Chef maintenance policy and Chef's MAINTAINERS.md document
- Ensure that future releases do not specifically break compatibility with RFC 19 workflows
Technical Direction
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.
Future Board Meetings
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.----
Shared via my feedly reader
Sent from my iPhone
No comments:
Post a Comment