[PATCH 12/17] docs: Convert 'governance' page to rST
Peter Krempa
pkrempa at redhat.com
Mon Mar 7 15:59:32 UTC 2022
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 at redhat.com>
---
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
More information about the libvir-list
mailing list