From 30941476a465748a42bc2327ab6ff3c8bf1264a7 Mon Sep 17 00:00:00 2001 From: Lars Kurth Date: Thu, 11 Aug 2016 17:56:39 +0100 Subject: [PATCH] Copied pandoc-converted variant of governance.html (v2.1) from xenproject.org to this repository Signed-off-by: Lars Kurth --- README.source | 15 ++ governance.pandoc | 544 ++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 559 insertions(+) create mode 100644 README.source create mode 100644 governance.pandoc diff --git a/README.source b/README.source new file mode 100644 index 0000000..ac4f669 --- /dev/null +++ b/README.source @@ -0,0 +1,15 @@ +The files in this directory are copied from the xenproject.org CMS and are maintained in this +repository. They have been translated from html to pandoc using a pandoc script to make the +changes more easily reviewable by the Xen Project community. + +Please make sure that your editor is set to wrap lines at 80 characters (80 because this will +make tables more easily readable). You can also use "fold -w 80 -s foo.pandoc"; however, you may have to manually correct tables it they are wider than 80 characters. + +The pandoc pages map to the following swebsitre locations +- governance.pandoc = https://xenproject.org/governance.html + +If you make changes to this directory, please ensure that community.manager@xenproject.org +is CC'ed to a patch. Otherwise the change will not be published on the website. + +All pandoc files in this repository are published CC BY 3.0 as stated in the terms of use +of https://xenproject.org/terms-of-use.html diff --git a/governance.pandoc b/governance.pandoc new file mode 100644 index 0000000..60fc942 --- /dev/null +++ b/governance.pandoc @@ -0,0 +1,544 @@ + +This document has come in effect in June 2011 and will be +reviewed periodically (see revision sections). The last modification has been +made in May 2013. + +Goals +----- + +The goals of Xen Project Governance are to: + +- Create a set of minimum requirements for a sub-project hosted on +Xenproject.org +- Create a lightweight project life cycle that + - leads the project to articulate its goals and how to achieve them + - encourages desired behaviours (e.g. open development) + - provides motivation for the project to succeed + - leads to non-viable projects failing quickly + - provides opportunities for other community members +- Avoid bureaucracy, i.e. the life cycle should be as informal as possible +- Encourage Xen related projects to be hosted on Xenproject.org rather than +going elsewhere +- Set clear expectations to vendors, upstream and downstream projects and +community members + +Principles +---------- + +### Openness + +The Xen Project is open to all and provides the same opportunity to all. +Everyone participates with the same rules. There are no rules to exclude any +potential contributors which include, of course, direct competitors in the +marketplace. + +### Transparency + +Project discussions, minutes, deliberations, project plans, plans for new +features, and other artefacts are open, public, and easily accessible. + +### Meritocracy + +The Xen Project is a meritocracy. The more you contribute the more +responsibility you will earn. Leadership roles in Xen are also merit-based and +earned by peer acclaim. + +### Consensus Decision Making + +Sub-projects or teams hosted on Xenproject.org are normally auto-governing and +driven by the people who volunteer for the job. This functions well for most +cases. When more formal decision making and coordination is required, decisions +are taken with a lazy consensus approach: a few positive votes with no negative +vote are enough to get going. + +Voting is done with numbers: + +- +1 : a positive vote +- 0 : abstain, have no opinion +- -1 : a negative vote + +A negative vote should include an alternative proposal or a detailed +explanation of the reasons for the negative vote. The project community then +tries to gather consensus on an alternative proposal that resolves the issue. +In the great majority of cases, the concerns leading to the negative vote can +be addressed. + +### Conflict Resolution + +#### Refereeing + +Sub-projects and teams hosted on Xenproject.org are not democracies but +meritocracies. In situations where there is disagreement on issues related to +the day-to-day running of the project, Committers and Project Leads are +expected to act as referees and make a decision on behalf of the community. +Referees should however consider whether making a decision may be divisive and +damaging for the community. In such cases, the committer community of the +project can privately vote on an issue, giving the decision more weight. + +#### Last Resort + +In some rare cases, the lazy consensus approach may lead to the community being +paralyzed. Thus, as a last resort when consensus cannot be achieved on a +question internal to a project, the final decision will be made by a private +majority vote amongst the committers and project lead. If the vote is tied, the +project lead gets an extra vote to break the tie. + +For questions that affect several projects, committers and project leads of +mature projects will hold a private majority vote. If the vote is tied, the +[Xen Project Advisory Board](/join.html) will break the tie through a casting +vote. + +Roles +----- + +### Maintainers + +Maintainers own one or several components in the Xen tree. A maintainer reviews +and approves changes that affect their components. It is a maintainer's prime +responsibility to review, comment on, co-ordinate and accept patches from other +community member's and to maintain the design cohesion of their components. +Maintainers are listed in a MAINTAINERS file in the root of the source tree. + +### Committers + +Committers are Maintainers that are allowed to commit changes into the source +code repository. The committer acts on the wishes of the maintainers and +applies changes that have been approved by the respective maintainer(s) to the +source tree. Due to their status in the community, committers can also act as +referees should disagreements amongst maintainers arise. Committers are listed +on the sub-project's team portal (e.g. [Hypervisor team +portal](/developers/teams/hypervisor.html)). + +### Sub-projects and Teams + +The Xen Project organizes itself into a number of sub-projects, which follow +the [Project Governance](#project-governance) (or Project Lifecycle) as +outlined in this document. Sub-projects (sometimes simply referred to as +projects) are run by individuals and are often referred to as teams to +highlight the collaborative nature of development. For example, each +sub-project has a [team portal](/developers/teams.html) on Xenproject.org. + +### Project Lead + +Sub-projects and teams hosted on Xenproject.org are managed by a Project Lead, +who also is a committer of the sub-project/team he/she leads. Project Leads are +the public figurehead of the project and is responsible for the health of the +project. Due to their status in the community, project leads can also act as +referees should disagreements amongst committers of the project arise. The +project lead typically also has write access to resources, such as the web page +of a specific project. + +### Xen Project Advisory Board + +The [Xen Project Advisory Board](/join.html) consists of members who are +committed to steering the project to advance its market and technical success, +and who serve as positive ambassadors for the project. The Xen Project Advisory +Board manages non-technical aspects of the Xen Project including funding for +shared project infrastructure, marketing and events, and managing the Xen +Project trademark. The Advisory Board leaves all technical decisions to the +open source meritocracy. + +### The Linux Foundation + +The Xen Project is a [Linux Foundation](/linux-foundation.html) Collaborative +Project. Collaborative Projects are independently funded software projects that +harness the power of collaborative development to fuel innovation across +industries and ecosystems. By spreading the collaborative DNA of the largest +collaborative software development project in history, The Linux Foundation +provides the essential collaborative and organizational framework so projects +can focus on innovation and results. + +### Mentor + +Younger projects may have a need for a mentor to help ensure that the project +will be successful. Mentors can be maintainers, project leads, advisory board +members or other distinguished community members. + +### Sponsor + +To form a new sub-project or team on Xenproject.org, we require a sponsor to +support the creation of the new project. A sponsor can be a project lead or +committer of a mature project, a member of the advisory board or the community +manager. This ensures that a distinguished community member supports the idea +behind the project. + +Making Contributions +-------------------- + +Making contributions in Xen follows the conventions as they are known in the +Linux Kernel community. In summary contributions are made through patches that +are reviewed by the community. Xen does not require community members to sign +contribution or committer agreements. We do require contributors to sign +contributions using the sign-off feature of the code repository, following the +same approach as the Linux Kernel does (see [Developer Certificate Of +Origin](http://elinux.org/Developer_Certificate_Of_Origin)). + +More information on making contributions can be found in the following +documents: + +- [Contribution Guidelines](g/help/contribution-guidelines.html) + +Elections and Formal Votes +-------------------------- + +### Maintainer Elections + +Developers who have earned the trust of maintainers (including the project +lead) can be promoted to Maintainer. A two stage mechanism is used + +- Nomination: A maintainer should nominate himself by proposing a patch to +the MAINTAINERS file or mailing a nomination to the project's mailing list. +Alternatively another maintainer may nominate a community member. A nomination +should explain the contributions of proposed maintainer to the project as well +as a scope (set of owned components). Where the case is not obvious, evidence +such as specific patches and other evidence supporting the nomination should be +cited. +- Confirmation: Normally, there is no need for a direct election to confirm a +new maintainer. Discussion should happen on the mailing list using the +principles of consensus decision making. If there is disagreement or doubt, the +project lead or a committer should ask the community manager to arrange a more +formal vote. + +### Committer Elections + +Developers who have earned the trust of committers in their project can through +election be promoted to Committer. A two stage mechanism is used + +- Nomination: Community members should nominate candidates by posting a +proposal to *appointments at xenproject dot org* explaining the candidate's +contributions to the project and thus why they should be elected to become a +Committer of the project. The nomination should cite evidence such as patches +and other contributions where the case is not obvious. Existing Committers will +review all proposals, check whether the nominee would be willing to accept the +nomination and publish suitable nominations on the project's public mailing +list for wider community input. +- Election: A committer will be elected using the decision making process +outlined earlier. Voting will be done by committers for that project privately +using a voting form that is created by the community manager. Should there be a +negative vote the project lead and community manager will try and resolve the +situation and reach consensus. Results will be published on the public mailing +list. + +### Project Lead Elections + +Projects which lose their project lead are at risk of failing. Should this +occur, the project's maintainer community should agree who would want to be/be +able to be the new project lead and follow the election process as outlined +above. + +### Formal Votes + +Sometimes it is necessary to conduct formal voting within the community +(outside of elections). Formal votes are necessary when processes and +procedures are introduced or changed, or as part of the [Project +Governance](#project-governance). Who is eligible to vote, depends on whether +the scope of a process or procedure is **local** to a sub-project or team, or +whether it affects **all sub-projects** (or in other words, is**global**). +Examples of local scope is the [Security Policy](/security-policy.html) which +applies to the [Hypervisor Project](/developers/teams/hypervisor.html) only. +Examples of global scope are changes to this document or votes outlined in the +Project Governance. + + ----------------------------------------------------------------------------- + **Scope** **Who reviews?** **Who votes?** + ------------ ---------------------- ----------------------------------------- + **Local** Members of developer Maintainers of the project (or projects), + mailing lists of the which are affected by the process, + affected projects. procedure, etc. are allowed to vote. + This includes maintainers from incubation + projects (if the scope affects the + project). + + **Global** Members of all Maintainers of **all mature** projects + developer mailing and the Xenproject.org community manager + lists of all are allowed to vote. + sub-projects hosted on + Xenproject.org. + ----------------------------------------------------------------------------- +\ + +The community manager first arranges a public review, followed by a timed +private vote. Public review and voting should be open for a minimum of a week +each. For voting a traceable poll mechanism (e.g. voting form that keeps +auditable and tamper proof records) must be used. Voting follows the +conventions as laid out in "Principle: Consensus Decision Making". + +Project Governance +------------------ + +### Basic Project Life Cycle + +The proposal is to follow a simple basic flow: + +![](images/articles/governance-xen_projectstages.png) + +A Xenproject.org hosted project starts with an idea which through the process +of project formation will grow into a project proposal. The project proposal +will need to satisfy some basic conditions, will be put out for community +review and is then put to a vote to all maintainers and project leads of mature +sub-projects hosted on Xenproject.org following the usual decision making +process. + +For agreed project proposals, the Xen Project will provide basic infrastructure +and the project can get started. Sub-projects in incubation are working towards +a set of goals, will get additional support and marketing opportunities from +the Xen Project. However there will also be regular checkpoints to see whether +the project is progressing. Should it turn out that a project is not viable any +more, it will be archived after an archivation review and vote. For a project +to graduate, some basic conditions must be satisfied. If a project in +incubation has achieved the point where it believes it is mature enough to +graduate, it can request a Graduation community review followed by a vote. + +Mature projects are pretty much expected to run themselves. However at some +point a mature project will lose momentum and developers. If this is the case +the Xen Project community can request an archivation review, which follows the +usual pattern. + +Archivation reviews have two purposes: + +- give somebody in the community an opportunity to step up and continue a +project, +- archive the project outcomes such that they are still available to people +who want to use them, but promotion of such projects will cease. + +It is also possible to revive archived projects. However these are treated +almost like new projects as projects would only be archived if they have become +inactive. + +### Requesting Reviews, Reviews and Voting + +**Requesting Reviews:** Project Proposal and Graduation Reviews are requested +by the (prospective) project lead of the project by contacting the community +manager providing the necessary documentation. An archivation review can be +requested by any maintainer of a mature project or by the Xen Project community +manager. The community manager will then publish relevant material on the +respective mailing lists. + +**Reviews:** These are off-line reviews which are open to all community members +by which a proposal is published for review. The purpose of the review is +two-fold: + +- gather final feedback and input from the community (it is good practice to +informally do this before the review), +- advertise the project with the aim to attract interest, users and +contributors. + +After a review, the requester of the review may decide to withdraw, request a +re-review or progress to a vote by arranging with the community manager. + +**Voting:** The community manager arranges a timed private vote as outlined in +[Formal Votes](#formal-votes). + +### Forming a Project + +Requirements for forming a sub-project or team on Xenproject.org: + +- A project needs a lead, who is willing to become the project lead of the +sub-project +- A project needs a sponsor, which can be a project lead of a mature project, +a member of the Xen Project Advisory Board or the community manager +- There should be no dissent from other community members who would qualify +as sponsor (see "Principle: Consensus Decision Making") +- A project needs a mentor, which can be the project sponsor or a maintainer +of a mature project +- A project needs to have a relationship to other sub-projects or teams, i.e. +it aims to develop software that has a dependency on other sub-projects or +teams hosted on Xenproject.org. If the project needs components in other +sub-projects to work, then this should also be stated. +- A project needs to be large and long-term enough to grant a separate +project. For example adding support for a new CPU architecture, adding +additional functionality on top of existing projects, etc. Adding a new feature +to an existing project should be performed within an existing project. +- A project will deliver code using a license that is compatible with other +sub-projects hosted on Xenproject.org (ideally GPLv2). + +The purpose of the project formation phase is to work out what the project is +about, get community buy-in and help the future project gain publicity and +momentum. The formation phase is driven by the project lead. The project +mentor's role is to advise and support the project lead in getting the project +started. + +The project proposal is a document that describes and is published on +[wiki.xenproject.org](http://wiki.xenproject.org): + +- What the project is aiming to achieve (i.e. the project charter and project +goals) +- What components/code and in which code lines (new or components in other +projects) the project aims to deliver +- Key dependencies on other sub-projects or teams hosted on Xenproject.org +(if applicable) +- Lists initial maintainers (if applicable) +- Lists any interested parties in the project (if applicable) +- Lists any planned initial code contributions (if applicable) +- A rough plan on how to get through the Incubation phase + +### Project Proposal Review + +The review is initiated by the project lead and follows the rules outlined in +"Requesting Reviews, Reviews and Voting". + +After a successful review, the following resources will be created for the +project: + +- A mailing list +- A codeline +- A sub-project or team portal on Xenproject.org (in an area separate from +mature projects) +- A wiki page on [wiki.xenproject.org](http://wiki.xenproject.org) (this is +expected to be maintained by the project lead) + +### Incubating a Project + +The purpose of the incubation phase is for a project to show that it is +gathering momentum and adheres to the "Principles & Roles" of sub-projects +hosted on Xenproject.org. The project mentor will work closely with the project +lead and there are at least quarterly informal review meetings with the mentor +on how the project is doing. Should a mentor not be able to fulfil his/her role +any more, it is the responsibility of the project lead to find another mentor. +We advise that the project lead gives at least quarterly updates on the Xen +Project blog on how the project is doing. + +The Xen Project will provide support to incubating projects. The project lead +will work closely with the Xen Project community manager as well as with the +project mentor. + +### Archiving an Incubating project + +The mentor can request for a project to be archived, if the project is not +making sufficient progress. See "archivation review". + +### Graduation Review + +The review is initiated by the project lead and follows the rules outlined in +"Requesting Reviews, Reviews and Voting". In essence the project lead makes a +pitch to the community, why the project should graduate. + +A project must fulfil the following requirements before it can graduate: + +- It follows the principles of openness, transparency and meritocracy +- It has delivered at least one functioning release of what it is aiming to +deliver +- It has a public code line which shows active development and has mechanisms +to accept patches (and a history of accepting patches) +- It has a public mailing list that is active (as we get more experience we +will add some guidelines) +- It has a mechanism for users to raise bugs and for developers to work on +bugs +- It has an active developer community (as we get more experience we will add +some guidelines). But things to look for are number of maintainers, different +organisations involved, number of users, etc. + +Other items to look at during the review (depending on project are): + +- It has an up-to-date wiki and a core and group of people maintaining it +- It publishes regular builds and tests +- It promotes itself at events and on the blog + +### Mature Projects + +Mature projects are expected to be run and promote themselves. The project lead +has significant responsibility in ensuring that this happens. The Xen Project +and the community manager will help organize events, provide opportunities for +the project to get new contributors and build a community, promote new releases +on the blog and to the press, work with project members, etc. However the Xen +Project and the community manager will not get involved in the day-to-day +running of the project. + +At some point during its life cycle a project may lose momentum. In other words +developers and users are not interested in the project any more. If this is the +case, it may be time to archive the project. If the project has achieved its +goals and is thus completed, it may also be time to archive the project. + +### Archivation Review + +These can happen in a number of situations: + +- An incubation project shows clear signs of failing and not progressing +- A mature project has lost its developer and user base (and there is little +or no activity) +- The project has achieved its goals and/or fulfilled its charter: in other +words it has completed + +In the first case the review is triggered by the incubation project's mentor. +Failing this the review can be requested by any maintainer of a mature project +(including the projec's lead) or by the Xen Project community manager. See +"Requesting Reviews, Reviews and Voting". + +The review is essentially a pitch why the project should be archived. The +purpose of the review is not necessarily to archive a project, but also to +provide a last opportunity for interested parties in the Xen Project community +to save the project and step up. The Xen Project community manager will support +efforts to save the project, should community members want to step up. There is +the special case that a project has been completed: in this case the normal +situation would be for the project lead to make the case, why this is so. + +### Archived Projects + +When a project is archived the following happens: + +- The codeline and mailing list will be made read-only and made accessible +from an archived projects section on Xenproject.org +- The project's wiki pages will be tagged as **archived**. A project may be +completed (i.e. it has achieved its goals and/or fulfilled its charter) in +which case it is tagged as **completed** and **archived**. +- The project or team portal on Xenproject.org will be moved into an +**Archive** section. We may have a **Completed** section within the **Archive** +section. + +In cases where the project has delivered code into other sub-projects hosted on +Xenproject.org, the code will be + +- Deprecated at the point where the project is archived +- The project which now contains the archived code can (but does not have to) +remove the code in a subsequent release (it should however give users +sufficient time to adapt) + +### Exceptional Circumstances + +#### Projects without Project Lead + +Projects which lose their project lead during the incubation or maturity phase +are at risk of failing. Should this occur, the project's maintainer community +should agree who would want to be/be able to be the new project lead and follow +the election process as outlined in "Electing Maintainers". + +If a project lead leaves during the formation phase, without finding a +successor we assume that the project does not have enough momentum and will not +go ahead. + +#### Incubation projects without Mentor + +Should an incubation project lose its mentor, the Xen Project community manager +will support the project lead in finding a new mentor. + +Change History +-------------- + +- **v2.1 May 2016:** Clarify Committer Elections as per this +[discussion](http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg0080 +1.html) and +[vote](http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg01614.html +) +- **v2.0 May 2012:** Changes to reflect transition from xen.org to +xenproject.org + - Added definitions for Sub-projects and Teams, Xen Project Advisory +Board and The Linux Foundation. + - Removed Xen.org Chairman as Referee of Last Resort and delegated this +role to the Xen Project Advisory Board. + - Allow Xen Project Advisory Board members to be Mentors. + - Clarify scope and eligible votes in Formal Votes; refer to this section +from Requesting Reviews, Reviews and Voting rather than duplicating + - Rename xen.org to xenproject.org or Xen Project throughout the document +(except in the history) + - Refer to sub-projects and teams instead of projects where appropriate +- **[v1.2](index.php?option=com_content&view=archive&year=2013&month=3) May +2012:** Minor changes + - Fixed typo and ambiguity in the role of Project Lead. + - Added section on Conflict Resolution. +- **v1.1 Oct 2011:** Minor changes + - Clarified the roles of Committer and Maintainer. + - Added Making Contributions which contains links to other documentation +and highlights that Xen.org required a DCO for contributions since 2005. +- **v1.0 Jun 2011:** Intial document approved + + \ No newline at end of file -- 2.39.5