QEMU Governance Model
Describe purpose of the project
PEG Community members will work collaboratively to add features to QEMU that fulfill their own needs and the needs of the community as a whole. Features will be added following the prpl Improvement Proposal process.
Discussion can occur in a number of different ways including via the GitHub issue tracker, the mailing list, and via in-person or web conferences. Meetings will be open to all members of the PEG community and will be announced on the mailing list with sufficient notice. Online meetings should be recorded and posted to a video sharing site. Posting these meetings provide a record of the discussion and allow for participation from those who are unable to participate at the normal meeting time.
Roles and Responsibilities
Each member of the community has one or more roles in the project. No role is more important than another. PEG community members consist of any individuals with interest in a project; they are not the same as prpl Foundation members.
Users are community members who have a need for the project. Without users, the project would have no purpose. Anyone can be a user; there are no specific requirements. Users should be encouraged to participate in the life of the project and the community as much as possible. User contributions enable the project team to ensure that they are satisfying the needs of those users. Common user activities include (but are not limited to):
- advocating for use of the project
- informing developers of project strengths and weaknesses from a new user's perspective
- providing moral support (a 'thank you' goes a long way)
- writing documentation and tutorials
- filing bug reports and feature requests
- participating on the discussion board
- propose changes to the code
- submit changes to the code under the project license
Users who continue to engage with the project and its community will often find themselves becoming more and more involved. Such users may then go on to become committers as described below.
Committers are members of the community with commit access to the project repository. Committers are responsible for ensuring code standards are enforced. Committers will regularly evaluate patch requests with the goal of maximum community participation in development while following code standards and verifying that the patches comply with the prpl IP Policy.
Committers will follow the standard procedure of making changes via pull requests. The only time a committer may push directly to the official repository is when they are fixing a conflict as part of merging a pull request.
Committers have a private mailing list email@example.com set up and observed by the Community Manager. The private list will only be used for discussing whether to add or remove PEG committers. This mailing list will have a private archive to document decisions and discussions. Decisions will be made via majority vote and votes must last at least 72 hours. If a committer is added or removed, it will be announced on the main mailing list.
Committers should be added based upon the peer acclaim with an appreciation of the unique experiences and skills of those and consistent with the prpl Rules of Engagement and Diversity policy. Of note, no member of the community may be excluded from committer participation based upon their employer or whether they are paid to work on the PEG.
The project is entitled to one representative on the prpl Foundation Technical Steering Committee (TSC). The community representative will use their own best judgment to represent the needs, thoughts and goals of the project community on the TSC.
Any member of the community may request an election for the project's community representative, provided that at least six months have passed since the last election. Elections for Community Representative will last at least seven days and will be decided by simple majority approval. All community members are eligible to vote.
Code modifications decision-making
The PEG uses different decision-making processes for buildable branches and feature branches. The wiki for the PEG will clearly specify which branches are “buildable branches.” In all cases, a -1 vote of a code modification is a veto of the code change.
Buildable branches are branches which are expected to contain code which will compile and pass most tests at all time. This code will be where releases are created from. Buildable branches include, at a minimum, the 'master' branch.
Additionally, any branches which correspond to a supported release are buildable branches. For example, if the project has a major version 2 which is supported and for which bug fixes are made, the branch for 2 will be a buildable branch.
Buildable branch code changes use the review-then-merge voting system. Buildable branches are expected to fully comply with project coding standards.
Feature branches are branches used for prototyping and building features. Feature branches should build at all times but it’s not an absolute requirement. While these branches should follow project coding standards, this is also not an absolute requirement.
Feature branch changes use the merge-then-review voting system. Once a feature branch is considered sufficiently mature, a feature branch can be submitted to the upstream QEMU project for inclusion in upstream QEMU.
Votes on whether a project is ready to be released use majority approval of the project community on the mailing list. Releases may not be vetoed. If anyone identifies serious problems in a potential release, members of the community should consider that in making their votes.
Procedural decisions are decided using simple majority approval of those voting.