+ The libvirt project operates as a meritocratic, consensus-based community. + Anyone with an interest in the project can join the community, contributing + to the ongoing development of the project's work. This pages describes how + that participation takes place and how contributors earn merit, and thus + influence, within the community. +
+ ++ The libvirt project community covers people from a wide variety of + countries, backgrounds and positions. This global diversity is a great + strength of the project, but can also lead to communication issues, + which may in turn cause unhappiness. To maximise happiness of the + project community taken as a whole, all members (whether users, + contributors or committers) are expected to abide by the project's + code of conduct. At a high level the code can be summarized as + "be excellant to each other". Expanding on this: +
+ ++ The users are anyone who has a need for the output of the project. + There are no rules or requirements to become a user of libvirt. Even + if the software does not yet work on their OS platform, a person can + be considered a potential future user and welcomed to participate. +
+ ++ Participation by users is key to ensuring the project moves in the + right direction, satisfying their real world needs. Users are + encouraged to participate in the broader libvirt community in any + number of ways: +
+ ++ The above is not an exhaustive list of things users can do to + participate in the project. Further ideas and suggestions are + welcome. Users are encouraged to take their participation + further and become contributors to the project in any of the + ways listed in the next section. +
+ ++ The contributors are community members who have some concrete impact + to the ongoing development of the project. There are many ways in which + members can contribute, with no requirement to be a software engineer. + Many users can in fact consider themselves contributors merely by + engaging in evangelism for the project. +
+ ++ The above is not an exhaustive list of things members can do to + contribute to the project. Further ideas and suggestions are + welcome. +
+ ++ There are no special requirements to becoming a contributor other + than having the interest and ability to provide a contribution. The + libvirt project does not require any + "Contributor License Agreement" + to be signed prior to engagement with the community. +
+ ++ In making a contribution to the project, the community member is + implicitly stating that they accept the terms of the license under + which the work they are contributing to is distributed. They are + also implicitly stating that they have the legal right to make the + contribution, if doing so on behalf of a broader organization / + company. Most of the project's code is distributed under the GNU + Lesser General Public License, version 2 or later. Details of the + exact license under which contributions will be presumed to be + covered are found in the source repositories, or website in question. +
+ ++ The committers are the subset of contributors who have direct access + to commit code to the project's primary source code repositories, which + are currently using the GIT software. The committers are chosen based + on the quality of their contributions over a period of time. This includes + both the quality of code they submit, as well as the quality of reviews + they provide on other contributors' submissions and a demonstration that + they understand day-to-day operation of the project and its goals. There + is no minimum level of contribution required in order to become a committer, + though 2-3 months worth of quality contribution would be a rough guide. +
+ ++ There are no special requirements to becoming a committer other than to + have shown a willingness and ability to contribute to the project over + an extended period of time. Proposals for elevating contributors to + committers are typically made by existing committers, though contributors + are also welcome to make proposals. The decision to approve the elevation + of a contributor to a committer is made through "rough consensus" between + the existing committers. +
+ ++ The aim in elevating contributors to committers is to ensure that there + is a broad base of experience and expertize across all areas of the + project's work. Committers are not required to have knowledge across + all areas of the project's work. While an approved committer has the + technical ability to commit code to any area of the project, by convention + they will only commit to areas they feel themselves to be qualified to + evaluate the contribution. If in doubt, committers will defer to the + opinion of other committers with greater expertize in an area. +
+ ++ The committers hold the ultimate control over what contributions are + accepted by the project, however, this does not mean they have the + right to do whatever they want. Where there is debate and disagreement + between contributors, committers are expected to look at the issues with + an unbiased point of view and help achieve a "rough consensus". If the + committer has a conflict of interest in the discussion, for example due + to their position of employment, they are expected to put the needs of + the community project first. If they cannot put the community project + first, they must declare their conflict of interest, and allow other + non-conflicted committers to make any final decision. +
+ ++ The committers are expected to monitor contributions to areas of the + project where they have expertize and ensure that either some form of + feedback is provided to the contributor, or to accept their contribution. + There is no formal minimum level of approval required to accept a + contribution. Positive review by any committer experienced in the area + of work is considered to be enough to justify acceptance in normal + circumstances. Where one committer explicitly rejects a contribution, + however, other committers should not override that rejection without + first establishing a "rough consensus" amongst the broader group of + committers. +
+ ++ Being a committer is a privilege, not a right. In exceptional + circumstances, the privilege may be removed from an active + contributor. Such decisions will be taken based on "rough + consensus" amongst other committers. In the event that a committer + is no longer able to participate in the project, after some period + of inactivity passes, they may be asked to confirm that they wish + to retain their role as a committer. +
+ ++ The security team consists of a subset of the project committers + along with representatives from vendors shipping the project's + software. The subset of project committers is chosen to be the + minimal size necessary to provide expertise spanning most of + the project's work. Further project committers may be requested + to engage in resolving specific security issues on a case by + case basis. Any vendor who is shipping the project's software + may submit a request for one or more of their representatives + to join the security team. Such requests must by approved by + existing members of the team vouching for the integrity of + the nominated person or organization. +
+ ++ Members of the security team are responsible for triaging and + resolving any security issues that are reported to the project. + They are expected to abide by the project's documented + security process. In particular + they must respect any embargo period agreed amongst the team + before disclosing a private issue. +
+ ++ A core concept for governance of the project described above is + that of "rough consensus". To expand on this, it is a process + of decision making that involves the following steps +
+ ++ To put this into words, any contributor is welcome to make a proposal + for consideration. Any contributor may participate in the discussions + around the proposal. The discussion will usually result in agreement + between the interested parties, or at least agreement between the + committers. Only in the very exceptional circumstance where there + is disagreement between committers, would a vote be considered. + Even in these exceptional circumstances, it is usually found to be + obvious what the majority opinion of the committers is. In the event + that even a formal vote is tied, the committers will have to hold + ongoing discussions until the stalemate is resolved or the proposal + withdrawn. +
+ ++ The overall goal of the "rough consensus" process is to ensure that + decisions can be made within the project, with a minimum level of + bureaucracy and process. Implicit in this is that any person who does + not explicitly reject to a proposal is assumed to be supportive, or + at least agnostic. +
+ + + + diff --git a/docs/index.html.in b/docs/index.html.in index 772cbfb648be4cf998a4f3a5cdb624257fcbd982..16bd6d5af687c003deef8a9b609ef69354c07a7e 100644 --- a/docs/index.html.in +++ b/docs/index.html.in @@ -30,6 +30,11 @@