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
