docs/governance.html.in

   1 <?xml version="1.0" encoding="UTF-8"?>
   2 <!DOCTYPE html>
   3 <html xmlns="http://www.w3.org/1999/xhtml">
   4   <body>
   5     <h1>Project governance</h1>
   6
   7     <ul id="toc"></ul>
   8
   9     <p>
  10       The libvirt project operates as a meritocratic, consensus-based community.
  11       Anyone with an interest in the project can join the community, contributing
  12       to the ongoing development of the project's work. This pages describes how
  13       that participation takes place and how contributors earn merit, and thus
  14       influence, within the community.
  15     </p>
  16
  17     <h2><a id="codeofconduct">Code of conduct</a></h2>
  18
  19     <p>
  20       The libvirt project community covers people from a wide variety of
  21       countries, backgrounds and positions. This global diversity is a great
  22       strength of the project, but can also lead to communication issues,
  23       which may in turn cause unhappiness. To maximise happiness of the
  24       project community taken as a whole, all members (whether users,
  25       contributors or committers) are expected to abide by the project's
  26       code of conduct. At a high level the code can be summarized as
  27       <em>"be excellent to each other"</em>. Expanding on this:
  28     </p>
  29
  30     <ul>
  31       <li><strong>Be respectful:</strong> disagreements between people are to
  32         be expected and are usually the sign of healthy debate and engagement.
  33         Disagreements can lead to frustration and even anger for some members.
  34         Turning to personal insults, intimidation or threatening behaviour does
  35         not improve the situation though. Participants should thus take care to
  36         ensure all communications / interactions stay professional at all times.</li>
  37
  38       <li><strong>Be considerate:</strong> remember that the community has members
  39         with a diverse background many of whom have English as a second language.
  40         What might appear impolite, may simply be a result of a lack of knowledge
  41         of the English language. Bear in mind that actions will have an impact
  42         on other community members and the project as a whole, so take potential
  43         consequences into account before pursuing a course of action.</li>
  44
  45       <li><strong>Be forgiving:</strong> humans are fallible and as such prone
  46         to make mistakes and inexplicably change their positions at times. Don't
  47         assume that other members are acting with malicious intent. Be prepared
  48         to forgive people who make mistakes and assist each other in learning
  49         from them. Playing a blame game doesn't help anyone.</li>
  50     </ul>
  51
  52     <h2><a id="roles">Roles and responsibilities</a></h2>
  53
  54     <h3><a href="users">Users</a></h3>
  55
  56     <p>
  57       The users are anyone who has a need for the output of the project.
  58       There are no rules or requirements to become a user of libvirt. Even
  59       if the software does not yet work on their OS platform, a person can
  60       be considered a potential future user and welcomed to participate.
  61     </p>
  62
  63     <p>
  64       Participation by users is key to ensuring the project moves in the
  65       right direction, satisfying their real world needs. Users are
  66       encouraged to participate in the broader libvirt community in any
  67       number of ways:
  68     </p>
  69
  70     <ul>
  71       <li>Evangelism: spread the word about what libvirt is doing, how it
  72         helps solve your problems. This can be via blog articles, social
  73         media postings, video blogs, user group / conference presentations
  74         and any other method of disseminating information</li>
  75       <li>Feedback: let the developers know about what does and does not
  76         work with the project. Talk to developers on the project's
  77         IRC channel and mailing list, or find them at conferences. Tell
  78         them what gaps the project has or where they should look for
  79         future development</li>
  80       <li>Moral support: developers live for recognition of the positive
  81         impact their work has on users' lives. Give thanks to the developers
  82         when evangelising the project, or when meeting them at user groups,
  83         conferences, etc.</li>
  84     </ul>
  85
  86     <p>
  87       The above is not an exhaustive list of things users can do to
  88       participate in the project. Further ideas and suggestions are
  89       welcome. Users are encouraged to take their participation
  90       further and become contributors to the project in any of the
  91       ways listed in the next section.
  92     </p>
  93
  94     <h3><a id="contributors">Contributors</a></h3>
  95
  96     <p>
  97       The contributors are community members who have some concrete impact
  98       to the ongoing development of the project. There are many ways in which
  99       members can contribute, with no requirement to be a software engineer.
 100       Many users can in fact consider themselves contributors merely by
 101       engaging in evangelism for the project.
 102     </p>
 103
 104     <ul>
 105       <li>Bug reporting: improve the quality of the project by reporting
 106         any problems found either to the project's own bug tracker, or to
 107         that of the OS vendor shipping the libvirt code.</li>
 108       <li>User help: join the <a href="contact.html">IRC channel or mailing list</a>
 109         to assist or advice other users in troubleshooting the problems they face.</li>
 110       <li>Feature requests: help set the direction for future work by
 111         reporting details of features which are missing to the project's
 112         own bug tracker or mailing lists.</li>
 113       <li>Graphical design: contribute to the development of the project's
 114         websites / wiki brand with improved graphics, styling or layout.</li>
 115       <li>Code development: write and submit patches to address bugs or implement
 116         new features</li>
 117       <li>Architectural design: improve the usefulness of the project
 118         by providing feedback on the design of proposed features, to
 119         ensure they satisfy the broadest applicable needs and survive
 120         the long term</li>
 121       <li>Code review: look at patches which are submitted and critique
 122         the code to identify bugs, potential design problems or other
 123         issues which should be addressed before the code is accepted</li>
 124       <li>Documentation: contribute to content on personal blogs, the
 125         website, wiki, code comments, or any of the formal documentation
 126         efforts.</li>
 127       <li>Translation: join the Fedora transifex community to improve the
 128         quality of translations needed by the libvirt project.</li>
 129       <li>Testing: try proposed patches or release candidates and report
 130         whether the build passes and the changes work as expected.</li>
 131     </ul>
 132
 133     <p>
 134       The above is not an exhaustive list of things members can do to
 135       contribute to the project. Further ideas and suggestions are
 136       welcome.
 137     </p>
 138
 139     <p>
 140       There are no special requirements to becoming a contributor other
 141       than having the interest and ability to provide a contribution. The
 142       libvirt project <strong>does not require</strong> any
 143       <em>"Contributor License Agreement"</em>
 144       to be signed prior to engagement with the community. However for
 145       contributing patches, providing a 'Signed-off-by' line with the
 146       author's legal name and e-mail address to demonstrate agreement
 147       and compliance with the <a href="https://developercertificate.org/">
 148       Developer Certificate of Origin</a> is required.
 149     </p>
 150
 151     <p>
 152       In making a non-patch contribution to the project, the community
 153       member is implicitly stating that they accept the terms of the license
 154       under which the work they are contributing to is distributed. They are
 155       also implicitly stating that they have the legal right to make the
 156       contribution, if doing so on behalf of a broader organization /
 157       company. Most of the project's code is distributed under the GNU
 158       Lesser General Public License, version 2.1 or later. Details of the
 159       exact license under which contributions will be presumed to be
 160       covered are found in the source repositories, or website in question.
 161     </p>
 162
 163     <h3><a id="committers">Committers</a></h3>
 164
 165     <p>
 166       The committers are the subset of contributors who have direct access
 167       to commit code to the project's primary source code repositories, which
 168       are currently using the GIT software. The committers are chosen based
 169       on the quality of their contributions over a period of time. This includes
 170       both the quality of code they submit, as well as the quality of reviews
 171       they provide on other contributors' submissions and a demonstration that
 172       they understand day-to-day operation of the project and its goals. There
 173       is no minimum level of contribution required in order to become a committer,
 174       though 2-3 months worth of quality contribution would be a rough guide.
 175     </p>
 176
 177     <p>
 178       There are no special requirements to becoming a committer other than to
 179       have shown a willingness and ability to contribute to the project over
 180       an extended period of time. Proposals for elevating contributors to
 181       committers are typically made by existing committers, though contributors
 182       are also welcome to make proposals. The decision to approve the elevation
 183       of a contributor to a committer is made through "rough consensus" between
 184       the existing committers.
 185     </p>
 186
 187     <p>
 188       The aim in elevating contributors to committers is to ensure that there
 189       is a broad base of experience and expertize across all areas of the
 190       project's work. Committers are not required to have knowledge across
 191       all areas of the project's work. While an approved committer has the
 192       technical ability to commit code to any area of the project, by convention
 193       they will only commit to areas they feel themselves to be qualified to
 194       evaluate the contribution. If in doubt, committers will defer to the
 195       opinion of other committers with greater expertize in an area.
 196     </p>
 197
 198     <p>
 199       The committers hold the ultimate control over what contributions are
 200       accepted by the project, however, this does not mean they have the
 201       right to do whatever they want. Where there is debate and disagreement
 202       between contributors, committers are expected to look at the issues with
 203       an unbiased point of view and help achieve a "rough consensus". If the
 204       committer has a conflict of interest in the discussion, for example due
 205       to their position of employment, they are expected to put the needs of
 206       the community project first. If they cannot put the community project
 207       first, they must declare their conflict of interest, and allow other
 208       non-conflicted committers to make any final decision.
 209     </p>
 210
 211     <p>
 212       The committers are expected to monitor contributions to areas of the
 213       project where they have expertize and ensure that either some form of
 214       feedback is provided to the contributor, or to accept their contribution.
 215       There is no formal minimum level of approval required to accept a
 216       contribution. Positive review by any committer experienced in the area
 217       of work is considered to be enough to justify acceptance in normal
 218       circumstances. Where one committer explicitly rejects a contribution,
 219       however, other committers should not override that rejection without
 220       first establishing a "rough consensus" amongst the broader group of
 221       committers.
 222     </p>
 223
 224     <p>
 225       Being a committer is a privilege, not a right. In exceptional
 226       circumstances, the privilege may be removed from an active
 227       contributor. Such decisions will be taken based on "rough
 228       consensus" amongst other committers. In the event that a committer
 229       is no longer able to participate in the project, after some period
 230       of inactivity passes, they may be asked to confirm that they wish
 231       to retain their role as a committer.
 232     </p>
 233
 234     <h3><a id="secteam">Security team</a></h3>
 235
 236     <p>
 237       The security team consists of a subset of the project committers
 238       along with representatives from vendors shipping the project's
 239       software. The subset of project committers is chosen to be the
 240       minimal size necessary to provide expertise spanning most of
 241       the project's work. Further project committers may be requested
 242       to engage in resolving specific security issues on a case by
 243       case basis. Any vendor who is shipping the project's software
 244       may submit a request for one or more of their representatives
 245       to join the security team. Such requests must by approved by
 246       existing members of the team vouching for the integrity of
 247       the nominated person or organization.
 248     </p>
 249
 250     <p>
 251       Members of the security team are responsible for triaging and
 252       resolving any security issues that are reported to the project.
 253       They are expected to abide by the project's documented
 254       <a href="securityprocess.html">security process</a>. In particular
 255       they must respect any embargo period agreed amongst the team
 256       before disclosing a private issue.
 257     </p>
 258
 259     <h2><a id="roughconsensus">Rough consensus</a></h2>
 260
 261     <p>
 262       A core concept for governance of the project described above is
 263       that of "rough consensus". To expand on this, it is a process
 264       of decision making that involves the following steps
 265     </p>
 266
 267     <ul>
 268       <li>Proposal</li>
 269       <li>Discussion</li>
 270       <li>Vote (exceptional circumstances only)</li>
 271       <li>Decision</li>
 272     </ul>
 273
 274     <p>
 275       To put this into words, any contributor is welcome to make a proposal
 276       for consideration. Any contributor may participate in the discussions
 277       around the proposal. The discussion will usually result in agreement
 278       between the interested parties, or at least agreement between the
 279       committers. Only in the very exceptional circumstance where there
 280       is disagreement between committers, would a vote be considered.
 281       Even in these exceptional circumstances, it is usually found to be
 282       obvious what the majority opinion of the committers is. In the event
 283       that even a formal vote is tied, the committers will have to hold
 284       ongoing discussions until the stalemate is resolved or the proposal
 285       withdrawn.
 286     </p>
 287
 288     <p>
 289       The overall goal of the "rough consensus" process is to ensure that
 290       decisions can be made within the project, with a minimum level of
 291       bureaucracy and process. Implicit in this is that any person who does
 292       not explicitly reject to a proposal is assumed to be supportive, or
 293       at least agnostic.
 294     </p>
 295
 296
 297   </body>
 298 </html>