libvirt/docs/governance.rst

==================
Project governance
==================

.. contents::

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 excellent to each other"*. Expanding on this:

-  **Be respectful:** 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.
-  **Be considerate:** 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.
-  **Be forgiving:** 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.

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:

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

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.

-  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.
-  User help: join the `IRC channel or mailing list <contact.html>`__ to assist
   or advice other users in troubleshooting the problems they face.
-  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.
-  Graphical design: contribute to the development of the project's websites /
   wiki brand with improved graphics, styling or layout.
-  Code development: write and submit patches to address bugs or implement new
   features
-  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
-  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
-  Documentation: contribute to content on personal blogs, the website, wiki,
   code comments, or any of the formal documentation efforts.
-  Translation: join the Fedora transifex community to improve the quality of
   translations needed by the libvirt project.
-  Testing: try proposed patches or release candidates and report whether the
   build passes and the changes work as expected.

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. However for contributing patches, providing a
'Signed-off-by' line with the author's chosen name and e-mail address to
demonstrate agreement and compliance with the `Developer Certificate
of Origin <hacking.html#developer-certificate-of-origin>`__ is required.

In making a non-patch 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.1 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 <securityprocess.html>`__. 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

-  Proposal
-  Discussion
-  Vote (exceptional circumstances only)
-  Decision

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.