On Mon, Feb 03, 2014 at 06:30:24PM +0000, Daniel P. Berrange wrote: > 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 prempt any potential, but unlikely, future problems. > > Signed-off-by: Daniel P. Berrange <berrange@xxxxxxxxxx> > --- > docs/governance.html.in | 292 ++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 292 insertions(+) > create mode 100644 docs/governance.html.in > > At FOSDEM this past weekend I was asked what the libvirt > governance process was. While I believe our community > members already understand all this, and it can be infered > from behaviour on lists, it will help future new contributors > to understand how we operate if we actually document it. > This is likely to be particularly helpful for other companies > wondering how to get involved in the libvirt project. > > diff --git a/docs/governance.html.in b/docs/governance.html.in > new file mode 100644 > index 0000000..8bc4e51 > --- /dev/null > +++ b/docs/governance.html.in > @@ -0,0 +1,292 @@ > +<?xml version="1.0" encoding="UTF-8"?> > +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";> > +<html xmlns="http://www.w3.org/1999/xhtml";> > + <body> > + <h1>Project governance</h1> > + > + <ul id="toc"></ul> > + > + <p> > + 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. > + </p> > + > + <h2><a name="codeofconduct">Code of conduct</a></h2> > + > + <p> > + 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 > + <em>"be excellant to each other"</em>. Expanding on this > + </p> > + > + <ul> > + <li><strong>Be respectful:</strong> disagreements between people are to > + be expected and are usually the sign of healthy debate and engagement. > + Disagreements can lead to frustration and even anger for some members. > + Turning to personal insults, intimidation or threatening behaviour does > + not improve the situation though. Participants should thus take care to > + ensure all communications / interactions stay professional at all times.</li> > + > + <li><strong>Be considerate:</strong> remember that the community has members > + with a diverse background many of whom have English as a second language. > + What might appear impolite, may simply be a result of a lack of knowledge > + of the English language. Bear in mind that actions will have an impact > + on other community members and the project as a whole, so take potential > + consequences into account before persuing a course of action.</li> > + > + <li><strong>Be forgiving:</strong> humans are fallible and as such prone > + to make mistakes and inexplicably change their positions at times. Don't > + assume that other members are acting with malicious intent. Be prepared > + to forgive people who make mistakes and assist each other in learning > + from them. Playing a blame game doesn't help anyone.</li> > + </ul> > + > + <h2><a name="roles">Roles and responsibilities</a></h2> > + > + <h3><a href="users">Users</a></h3> > + > + <p> > + 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. > + </p> > + > + <p> > + Participation by users is key to ensuring the project moves in the > + right direction, satisfying their real world needs. Users are > + encouraged in participate in the broader libvirt community in any Nit-pick: s/encouraged in/encouraged to > + number of ways: > + </p> > + > + <ul> > + <li>Evangelism: spread the word about what libvirt is doing, how it > + helps solve your problems. This can be via blog articles, social > + media postings, video blogs, user group / conference presentations > + and any other method of diseminating information</li> > + <li>Feedback: let the developers know about what does and does not > + work with the project. Talk to developers on the project's > + IRC channel and mailing list, or find them at conferences. Tell > + them what gaps the project has or where they should look for > + future development</li> > + <li>Moral support: developers live for recognition of the positive > + impact their work has on users' lives. Give thanks to the developers > + when evangelising the project, or when meeting them at user groups, > + conferences, etc.</li> > + </ul> > + > + <p> > + 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. > + </p> > + > + <h3><a name="contributors">Contributors</a></h3> > + > + <p> > + 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. > + </p> > + > + <ul> > + <li>Bug reporting: improve the quality of the project by reporting > + any problems found either to the project's own bug tracker, or to > + that of the OS vendor shipping the libvirt code.</li> > + <li>User help: join the IRC channel or mailing list to assist or advice > + other users in troubleshooting the problems they face.</li> > + <li>Feature requests: help set the direction for future work by > + reporting details of features which are missing to the project's > + own bug tracker or mailing lists.</li> > + <li>Graphical design: contribute to the development of the project's > + websites / wiki brand with improved graphics, styling or layout.</li> > + <li>Code development: write and submit patches to address bugs or implement > + new features</li> > + <li>Architectural design: improve the usefulness of the project > + by providing feedback on the design of proposed features, to > + ensure they satisfy the broadest applicable needs and an survive > + the long term</li> s/and an survive/and survive > + <li>Code review: look at patches which are submitted and critique > + the code to identify bugs, potential design problems or other > + issues which should be addressed before the code is accepted</li> > + <li>Documentation: contribute to content on personal blogs, the > + website, wiki, code comments, or any of the formal documentation > + efforts.</li> > + <li>Translation: join the Fedora transifex community to improve the > + quality of translations needed by the libvirt project.</li> > + </ul> > + > + <p> > + The above is not an exhaustive list of things members can do to > + contribute to the project. Further ideas and suggestions are > + welcome. > + </p> > + > + <p> > + There are no special requirements to becoming a contributor other > + than having the interest and ability to provide a contribution. The > + libvirt project <strong>does not require</strong> any > + <em>"Contributor License Agreement"</em> > + to be signed prior to engagement with the community. > + </p> > + > + <p> > + 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. > + </p> > + > + <h3><a name="committers">Committers</a></h3> > + > + <p> > + 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 projet 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. > + </p> > + > + <p> > + 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 comitters, 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. > + </p> > + > + <p> > + 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. > + </p> > + > + <p> > + 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. > + </p> > + > + <p> > + 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. > + </p> > + > + <p> > + 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 rights as a committer. > + </p> > + > + <h3><a name="secteam">Security team</a></h3> > + > + <p> > + 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 neccessary 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. > + </p> > + > + <p> > + 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 > + <a href="securityprocess.html">security process</a>. In particular > + they must respect any embargo period agreed amongst the team > + before disclosing a private issue. > + </p> > + > + <h2><a name="roughconsensus">Rough consensus</a></h2> > + > + <p> > + 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 > + </p> > + > + <ul> > + <li>Proposal</li> > + <li>Discussion</li> > + <li>Vote (exceptional circumstances only)</li> > + <li>Decision</li> > + </ul> > + > + <p> > + 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 be tied, the committers will have to hold > + ongoing discussions until the stalemate is resolved or the proposal > + withdrawn. > + </p> > + > + <p> > + 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. > + </p> > + > + > + </body> > +</html> > Nicely articulated. ACK, FWIW. -- /kashyap > -- > 1.8.5.3 > > -- > libvir-list mailing list > libvir-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/libvir-list -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list