--- /dev/null
+<?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 pursuing 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 to participate in the broader libvirt community in any
+ 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 disseminating 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 <a href="contact.html">IRC channel or mailing list</a>
+ 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 survive
+ the long term</li>
+ <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>
+ <li>Testing: try proposed patches or release candidates and report
+ whether the build passes and the changes work as expected.</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 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.
+ </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 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.
+ </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 role 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 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.
+ </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 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>
projects / libvirt.git / commitdiff