From e45b07314e27f97730b2c6c58153de396bf4e5d3 Mon Sep 17 00:00:00 2001 From: "Daniel P. Berrange" Date: Mon, 3 Feb 2014 18:24:49 +0000 Subject: [PATCH] Write up the project governance process The project has historically operated as a meritocratic consensus based community. Formally document what has always been an unwritten assumption amongst the community participants. Also include an explicit code of conduct to preempt any potential, but unlikely, future problems. Signed-off-by: Daniel P. Berrange --- docs/governance.html.in | 294 ++++++++++++++++++++++++++++++++++++++++ docs/index.html.in | 5 + docs/sitemap.html.in | 4 + 3 files changed, 303 insertions(+) create mode 100644 docs/governance.html.in diff --git a/docs/governance.html.in b/docs/governance.html.in new file mode 100644 index 0000000000..e649f08aba --- /dev/null +++ b/docs/governance.html.in @@ -0,0 +1,294 @@ + + + + +

Project governance

+ + + +

+ 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. +

+ +

Code of conduct

+ +

+ 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: +

+ + + +

Roles and responsibilities

+ +

Users

+ +

+ 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. +

+ +

Contributors

+ +

+ 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. +

+ +

Committers

+ +

+ 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. +

+ +

Security team

+ +

+ 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. +

+ +

Rough consensus

+ +

+ 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 772cbfb648..16bd6d5af6 100644 --- a/docs/index.html.in +++ b/docs/index.html.in @@ -30,6 +30,11 @@
  • A QMF agent for the AMQP/QPid messaging system
    • +
  • + A technical meritocracy, in which + participants gain influence over a project through recognition + of their contributions. +

    • libvirt supports:

    diff --git a/docs/sitemap.html.in b/docs/sitemap.html.in index 60daf153fb..08c2fbddc9 100644 --- a/docs/sitemap.html.in +++ b/docs/sitemap.html.in @@ -352,6 +352,10 @@ Virsh Commands Command reference for virsh +
  • + Governance + Project governance and code of conduct +
  • -- GitLab