[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH] Write up the project governance process



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 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 redhat com
> https://www.redhat.com/mailman/listinfo/libvir-list


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]