mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2024-08-28 11:31:16 +00:00
228 lines
12 KiB
ReStructuredText
228 lines
12 KiB
ReStructuredText
|
==================
|
||
|
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 legal name and e-mail address to
|
||
|
demonstrate agreement and compliance with the `Developer Certificate of
|
||
|
Origin <https://developercertificate.org/>`__ 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.
|