[libvirt] [PATCH] Write up the project governance process
Kashyap Chamarthy
kchamart at redhat.com
Mon Feb 3 20:56:53 UTC 2014
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 at redhat.com>
> ---
> 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 at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
More information about the libvir-list
mailing list