[PATCH 12/17] docs: Convert 'governance' page to rST

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

 



Extra care is taken to preserve the 'codeofconduct' anchor which is used
in our page template. Upcoming patch will change that but we'll retain
the anchor.

Signed-off-by: Peter Krempa <pkrempa@xxxxxxxxxx>
---
 docs/governance.html.in | 298 ----------------------------------------
 docs/governance.rst     | 232 +++++++++++++++++++++++++++++++
 docs/meson.build        |   2 +-
 3 files changed, 233 insertions(+), 299 deletions(-)
 delete mode 100644 docs/governance.html.in
 create mode 100644 docs/governance.rst

diff --git a/docs/governance.html.in b/docs/governance.html.in
deleted file mode 100644
index 61ab52c858..0000000000
--- a/docs/governance.html.in
+++ /dev/null
@@ -1,298 +0,0 @@
-<?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. 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 <a href="https://developercertificate.org/";>
-      Developer Certificate of Origin</a> is required.
-    </p>
-
-    <p>
-      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.
-    </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>
diff --git a/docs/governance.rst b/docs/governance.rst
new file mode 100644
index 0000000000..df90ce678d
--- /dev/null
+++ b/docs/governance.rst
@@ -0,0 +1,232 @@
+.. role:: anchor(raw)
+   :format: html
+
+==================
+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.
+
+:anchor:`<a id="codeofconduct"/>`
+
+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.
diff --git a/docs/meson.build b/docs/meson.build
index ab020ab090..08c324a74b 100644
--- a/docs/meson.build
+++ b/docs/meson.build
@@ -50,7 +50,6 @@ docs_html_in_files = [
   'formatsecret',
   'formatstoragecaps',
   'formatstorageencryption',
-  'governance',
   'hooks',
   'index',
   'internals',
@@ -98,6 +97,7 @@ docs_rst_files = [
   'formatstorage',
   'glib-adoption',
   'goals',
+  'governance',
   'hacking',
   'libvirt-go',
   'libvirt-go-xml',
-- 
2.35.1




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux