| RFC | Author | Status | Type |
|---|---|---|---|
30 |
Adam Jacob <[email protected]> |
Accepted |
Process |
The Maintenance Policy defines how we make decisions about what happens with Chef, and associated software projects. It provides the process by which:
- Roadmaps are decided
- Patches are merged
- Disputes are resolved
It is intended to be short, flexible, and clear.
This file is related to the MAINTAINERS file in Chef. During the draft period, the first version of that file is included in this RFC.
This file is the canonical source for how the Chef project is maintained.
Resolves disputes Provides vision and roadmap Has universal veto power
Publish a roadmap (two quarters out) Release calendar for code outside of chef client/chef server Resolves disputes within their subsystem Has localized veto power Plus all responsibilities of a maintainer
Handle contributions on GitHub - first response to a PR within 48 hours Be available on IRC Attend the developers meeting (do not miss more than 3 in a row - special dispensation can be made for difficult time zones) Be available to answer mailing list questions within 48 hours Weekends and local holidays in the maintainer’s jurisdiction are not counted for timeliness requirements. Absences for reasonable causes such as vacations, illness, etc. are also acceptable; Maintainers should notice of absences via the development mailing list whenever possible. Committed to 100% tests passing for your component Has full commit/merge access to the relevant repositories Has ops on IRC
##How a patch gets merged
- Open Pull Request (anyone)
- Sign a CLA on Supermarket, tied to your github account.
- Code reviewed by a maintainer, lieutenant, or project lead. Approval is indicated by 👍 on the pull request.
- Merged on 👍 by an absolute majority of maintainers for the subsystems affected by your patch with no vetoes
Although the approval of a contribution requires an absolute majority of the maintainers responsible for that component to vote for it, there may be cases where someone wishes to appeal a particular decision.
In this event, the "chain of command" for the appeals process is as follows.
-
In the event that the actions of a Maintainer are to be appealed, the appeal should be directed to the Lieutenant for that component. As stated above, a Lt retains veto power for the component(s) for which they are responsible.
-
In the event that the actions of a Lieutenant are to be appealed, the appeal should be directed to the Project Lead. As stated above, the Project Lead retains universal veto power over all components.
Although Lieutenants and the Project Lead retain veto powers over certain components, use of this veto power is not guaranteed by the submission of an appeal to that person. It is expected that the majority decisions of component maintainers and lieutenants will be respected in all but the most exceptional circumstances.
- Have patches merged into the relevant subsystem
- Be willing to perform the duties of a maintainer
- Issue a pull request adding yourself to the MAINTAINERS file for your component
- Receive an absolute majority of existing maintainers and lieutenants for your component 👍
- No veto from the component lieutenant
- No veto from the current project lead
- Issue a pull request to the MAINTAINERS file making yourself the lieutenant
- Be willing to perform the duties of a lieutenant
- Receive an absolute majority of existing lieutenants 👍
- No veto from the current project lead
- Issue a pull request to the MAINTAINERS file making yourself the project lead
- Be willing to perform the duties of the project lead
- Receive an absolute majority of existing lieutenants 👍
- No veto from Chef Software, Inc, as held by their current Chief Executive Officer.
If a Maintainer, Lieutenant or Lead consistently fails to maintain their responsibilities or becomes disruptive, they can be removed by:
- Issue a pull request removing them from the MAINTAINERS file
- Receive an absolute majority of existing lieutentants 👍
- No veto from the current project lead
OR
- Issue a pull request removing them from the MAINTAINERS file
- The current project lead unilaterally decides to merge pull request
- Issue a pull request to the MAINTAINERS file describing the component, and making yourself lieutenant
- Be willing to perform the duties of a lieutenant
- Receive an absolute majority of existing lieutenants 👍
- No veto from the current project lead
- Issue a pull request to this file.
- Receive an absolute majority of existing lieutenants from the Chef repository MAINTAINERS file 👍
- No veto from the current project lead
The broader Chef community gathers in a small number of designated places. Participants in these places should be considered as operating on their own opinion, and representing nothing further than their own point of view. While some members of the community may be participating via their employment at Chef Software, when in these spaces, their authority and voice is equal to any other participant based on the guidelines in this file.
You can find a large set of community members in IRC, within the #chef channel on irc.freenode.net. Development updates and conversations also happen on #chef-hacking. In both channels, those with “ops” are the maintainers, lieutenants, and the project lead. Those with “voice” are MVPs for Chef releases.
- Chef Users - is the primary async communications channel for all users of Chef, regardless of how they participate.
- Chef Developers - is the primary async communications channel for those concerned with developing Chef.
The history of the Chef Project is linked to the existence of a for-profit company, Chef Software. Many employees of the company are active members of the community. When they participate in the community, they do so as individuals subject to the guidelines in this file.
If you would like to speak to, or understand the position of, someone at Chef Software - feel free to drop a line to [email protected] - and we’ll get back to you. Or simply ask for the companies official perspective in any of the community spaces, and a representative will get back to you in that space.
This file lists how the Chef project is maintained. When making changes to the system, this file tells you who needs to review your patch - you need a simple majority of maintainers for the relevant subsystems to provide a 👍 on your pull request. Additionally, you need to not receive a veto from a Lieutenant or the Project Lead.
Check out HOW_CHEF_IS_MAINTAINED for details on the process, how to become a maintainer, lieutenant, or the project lead.
Handles the core parts of the Chef DSL, base resource and provider infrastructure, and the Chef applications. Includes anything not covered by another component.
Chef Zero, Knife, Chef Apply and Chef Shell.
ChefSpec, Berkshelf (the chef bits), Test Kitchen (the Chef bits)
The specific components of Chef related to a given platform - including (but not limited to) resources, providers, and the core DSL.