--- /dev/null
+
+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:
+
+
+
+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
projects / people / larsk / governance.git / commitdiff