mirror of https://gitee.com/openkylin/libvirt.git
295 lines
14 KiB
XML
295 lines
14 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE html>
|
|
<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 id="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 excellent 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 id="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 id="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 id="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 id="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 id="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>
|