--- /dev/null
+<p>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.</p>
+<p><a id="goals"></a></p>
+<h2>Goals</h2>
+<p>The goals of Xen Project Governance are to:</p>
+<ul>
+<li>Create a set of minimum requirements for a sub-project hosted on
+Xenproject.org</li>
+<li>Create a lightweight project life cycle that
+<ul>
+<li>leads the project to articulate its goals and how to achieve them</li>
+<li>encourages desired behaviours (e.g. open development)</li>
+<li>provides motivation for the project to succeed</li>
+<li>leads to non-viable projects failing quickly</li>
+<li>provides opportunities for other community members</li>
+</ul>
+</li>
+<li>Avoid bureaucracy, i.e. the life cycle should be as informal as
+possible</li>
+<li>Encourage Xen related projects to be hosted on Xenproject.org rather
+than going elsewhere</li>
+<li>Set clear expectations to vendors, upstream and downstream projects
+and community members</li>
+</ul>
+<p><a id="principles"></a></p>
+<h2>Principles</h2>
+<h3>Openness</h3>
+<p>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.</p>
+<h3>Transparency</h3>
+<p>Project discussions, minutes, deliberations, project plans, plans for
+new features, and other artefacts are open, public, and easily
+accessible.</p>
+<h3>Meritocracy</h3>
+<p>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.</p>
+<h3>Consensus Decision Making</h3>
+<p>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.</p>
+<p>Voting is done with numbers:</p>
+<ul>
+<li>+1 : a positive vote</li>
+<li>0 : abstain, have no opinion</li>
+<li>-1 : a negative vote</li>
+</ul>
+<p>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.<a id="conflict"> </a></p>
+<h3>Conflict Resolution</h3>
+<h4>Refereeing</h4>
+<p>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.</p>
+<h4>Last Resort</h4>
+<p>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.</p>
+<p>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 <a
+href="index.php?option=com_content&view=article&id=122:join-as-a-co
+rporate-member&catid=83:about&Itemid=717">Xen Project Advisory
+Board</a> will break the tie through a casting vote.</p>
+<p><a id="roles"></a></p>
+<h2>Roles</h2>
+<h3>Maintainers</h3>
+<p>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.</p>
+<h3>Committers</h3>
+<p>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. <a
+href="index.php?option=com_content&view=article&id=82:xen-hyperviso
+r&catid=80:developers&Itemid=484">Hypervisor team portal</a>).</p>
+<h3>Sub-projects and Teams</h3>
+<p>The Xen Project organizes itself into a number of sub-projects, which
+follow the <a href="#project-governance">Project Governance</a> (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 <a
+href="index.php?option=com_content&view=article&id=80:projects&
+catid=80:developers&Itemid=482">team portal</a> on Xenproject.org.</p>
+<h3>Project Lead</h3>
+<p>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.</p>
+<h3>Xen Project Advisory Board</h3>
+<p>The <a
+href="index.php?option=com_content&view=article&id=122:join-as-a-co
+rporate-member&catid=83:about&Itemid=717">Xen Project Advisory
+Board</a> 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.</p>
+<h3>The Linux Foundation</h3>
+<p>The Xen Project is a <a
+href="index.php?option=com_content&view=article&id=101:linux-founda
+tion&catid=85:about-xen&Itemid=525">Linux Foundation</a>
+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.</p>
+<h3>Mentor</h3>
+<p>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.</p>
+<h3>Sponsor</h3>
+<p>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.</p>
+<h2>Making Contributions</h2>
+<p>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 <a
+href="http://elinux.org/Developer_Certificate_Of_Origin">Developer
+Certificate Of Origin</a>).</p>
+<p>More information on making contributions can be found in the following
+documents:</p>
+<ul>
+<li><a
+href="index.php?option=com_content&view=article&id=130:contribution
+-guidelines&catid=82:help&Itemid=742">Contribution
+Guidelines</a></li>
+</ul>
+<h2>Elections and Formal Votes</h2>
+<h3>Maintainer Elections</h3>
+<p>Developers who have earned the trust of maintainers (including the
+project lead) can be promoted to Maintainer. A two stage mechanism is
+used</p>
+<ul>
+<li>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.</li>
+<li>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.</li>
+</ul>
+<h3>Committer Elections</h3>
+<p>Developers who have earned the trust of committers in their project can
+through election be promoted to Committer. A two stage mechanism is
+used</p>
+<ul>
+<li>Nomination: Community members should nominate candidates by posting a
+proposal to <em>appointments at xenproject dot org</em> 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.</li>
+<li>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.</li>
+</ul>
+<h3>Project Lead Elections</h3>
+<p>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.</p>
+<p><a id="formal-votes"></a></p>
+<h3>Formal Votes</h3>
+<p>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 <a
+href="#project-governance">Project Governance</a>. Who is eligible to
+vote, depends on whether the scope of a process or procedure is
+<b>local</b> to a sub-project or team, or whether it affects <b>all
+sub-projects</b> (or in other words, is<strong> global</strong>). Examples
+of local scope is the <a
+href="index.php?option=com_content&view=article&id=97:security-poli
+cy&catid=85:about-xen&Itemid=521">Security Policy</a> which
+applies to the <a
+href="index.php?option=com_content&view=article&id=82:xen-hyperviso
+r&catid=80:developers&Itemid=484">Hypervisor Project</a> only.
+Examples of global scope are changes to this document or votes outlined in
+the Project Governance.</p>
+<p>
+<table class="zebra">
+<tbody>
+<tr>
+<td width="10%"><b>Scope</b></td>
+<td width="45%"><b>Who reviews?</b></td>
+<td width="45%"><b>Who votes?</b></td>
+</tr>
+<tr>
+<td><b>Local</b></td>
+<td>Members of developer mailing lists of the affected projects.</td>
+<td>Maintainers of the project (or projects), which are affected by the
+process, procedure, etc. are allowed to vote. This includes maintainers
+from incubation projects (if the scope affects the project).</td>
+</tr>
+<tr>
+<td><b>Global</b></td>
+<td>Members of all developer mailing lists of all sub-projects hosted on
+Xenproject.org.</td>
+<td>Maintainers of <b>all mature</b> projects and the Xenproject.org
+community manager are allowed to vote.</td>
+</tr>
+</tbody>
+</table>
+</p>
+<p>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".</p>
+<p><a id="project-governance"></a></p>
+<h2>Project Governance</h2>
+<h3>Basic Project Life Cycle</h3>
+<p>The proposal is to follow a simple basic flow:</p>
+<p><img alt="governance-xen projectstages"
+src="images/articles/governance-xen_projectstages.png" height="452"
+width="901" /></p>
+<p>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.</p>
+<p>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.</p>
+<p>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.</p>
+<p>Archivation reviews have two purposes:</p>
+<ul>
+<li>give somebody in the community an opportunity to step up and continue
+a project,</li>
+<li>archive the project outcomes such that they are still available to
+people who want to use them, but promotion of such projects will
+cease.</li>
+</ul>
+<p>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.<a id="project.requests"> </a></p>
+<h3>Requesting Reviews, Reviews and Voting</h3>
+<p><strong>Requesting Reviews:</strong> 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.</p>
+<p><strong>Reviews:</strong> 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:</p>
+<ul>
+<li>gather final feedback and input from the community (it is good
+practice to informally do this before the review),</li>
+<li>advertise the project with the aim to attract interest, users and
+contributors.</li>
+</ul>
+<p>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.</p>
+<p><strong>Voting:</strong> The community manager arranges a timed private
+vote as outlined in <a href="#formal-votes">Formal Votes</a>.</p>
+<h3>Forming a Project</h3>
+<p>Requirements for forming a sub-project or team on Xenproject.org:</p>
+<ul>
+<li>A project needs a lead, who is willing to become the project lead of
+the sub-project</li>
+<li>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</li>
+<li>There should be no dissent from other community members who would
+qualify as sponsor (see "Principle: Consensus Decision Making")</li>
+<li>A project needs a mentor, which can be the project sponsor or a
+maintainer of a mature project</li>
+<li>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.</li>
+<li>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.</li>
+<li>A project will deliver code using a license that is compatible with
+other sub-projects hosted on Xenproject.org (ideally GPLv2).</li>
+</ul>
+<p>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.</p>
+<p>The project proposal is a document that describes and is published on
+<a href="http://wiki.xenproject.org">wiki.xenproject.org</a>:</p>
+<ul>
+<li>What the project is aiming to achieve (i.e. the project charter and
+project goals)</li>
+<li>What components/code and in which code lines (new or components in
+other projects) the project aims to deliver</li>
+<li>Key dependencies on other sub-projects or teams hosted
+on Xenproject.org (if applicable)</li>
+<li>Lists initial maintainers (if applicable)</li>
+<li>Lists any interested parties in the project (if applicable)</li>
+<li>Lists any planned initial code contributions (if applicable)</li>
+<li>A rough plan on how to get through the Incubation phase</li>
+</ul>
+<h3>Project Proposal Review</h3>
+<p>The review is initiated by the project lead and follows the rules
+outlined in "Requesting Reviews, Reviews and Voting".</p>
+<p>After a successful review, the following resources will be created for
+the project:</p>
+<ul>
+<li>A mailing list</li>
+<li>A codeline</li>
+<li>A sub-project or team portal on Xenproject.org (in an area separate
+from mature projects)</li>
+<li>A wiki page on <a
+href="http://wiki.xenproject.org">wiki.xenproject.org</a> (this is
+expected to be maintained by the project lead)</li>
+</ul>
+<h3>Incubating a Project</h3>
+<p>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.</p>
+<p>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.</p>
+<h3>Archiving an Incubating project</h3>
+<p>The mentor can request for a project to be archived, if the project is
+not making sufficient progress. See "archivation review".</p>
+<h3>Graduation Review</h3>
+<p>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.</p>
+<p>A project must fulfil the following requirements before it can
+graduate:</p>
+<ul>
+<li>It follows the principles of openness, transparency and
+meritocracy</li>
+<li>It has delivered at least one functioning release of what it is aiming
+to deliver</li>
+<li>It has a public code line which shows active development and has
+mechanisms to accept patches (and a history of accepting patches)</li>
+<li>It has a public mailing list that is active (as we get more experience
+we will add some guidelines)</li>
+<li>It has a mechanism for users to raise bugs and for developers to work
+on bugs</li>
+<li>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.</li>
+</ul>
+<p>Other items to look at during the review (depending on project are):</p>
+<ul>
+<li>It has an up-to-date wiki and a core and group of people maintaining
+it</li>
+<li>It publishes regular builds and tests</li>
+<li>It promotes itself at events and on the blog</li>
+</ul>
+<h3>Mature Projects</h3>
+<p>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.</p>
+<p>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.</p>
+<h3>Archivation Review</h3>
+<p>These can happen in a number of situations:</p>
+<ul>
+<li>An incubation project shows clear signs of failing and not
+progressing</li>
+<li>A mature project has lost its developer and user base (and there is
+little or no activity)</li>
+<li>The project has achieved its goals and/or fulfilled its charter: in
+other words it has completed</li>
+</ul>
+<p>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".</p>
+<p>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.</p>
+<h3>Archived Projects</h3>
+<p>When a project is archived the following happens:</p>
+<ul>
+<li>The codeline and mailing list will be made read-only and made
+accessible from an archived projects section on Xenproject.org</li>
+<li>The project's wiki pages will be tagged as <strong>archived</strong>.
+A project may be completed (i.e. it has achieved its goals and/or
+fulfilled its charter) in which case it is tagged as
+<strong>completed</strong> and <strong>archived</strong>.</li>
+<li>The project or team portal on Xenproject.org will be moved into an
+<strong>Archive</strong> section. We may have a <strong>Completed</strong>
+section within the <strong>Archive</strong> section.</li>
+</ul>
+<p>In cases where the project has delivered code into other sub-projects
+hosted on Xenproject.org, the code will be</p>
+<ul>
+<li>Deprecated at the point where the project is archived</li>
+<li>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)</li>
+</ul>
+<h3>Exceptional Circumstances</h3>
+<h4>Projects without Project Lead</h4>
+<p>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".</p>
+<p>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.</p>
+<h4>Incubation projects without Mentor</h4>
+<p>Should an incubation project lose its mentor, the Xen Project community
+manager will support the project lead in finding a new mentor.</p>
+<h2>Change History</h2>
+<div class="box-note">
+<ul>
+<li><strong><strong>v2.1 May 2016:</strong></strong> Clarify
+Committer Elections as per this <a
+href="http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg00801.
+html">discussion</a> and <a
+href="http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg01614.
+html">vote</a></li>
+<li><strong>v2.0 May 2012:</strong> Changes to reflect transition from
+xen.org to xenproject.org
+<ul>
+<li>Added definitions for Sub-projects and Teams, Xen Project Advisory
+Board and The Linux Foundation.</li>
+<li>Removed Xen.org Chairman as Referee of Last Resort and delegated this
+role to the Xen Project Advisory Board.</li>
+<li>Allow Xen Project Advisory Board members to be Mentors.</li>
+<li>Clarify scope and eligible votes in Formal Votes; refer to this
+section from Requesting Reviews, Reviews and Voting rather than
+duplicating</li>
+<li>Rename xen.org to xenproject.org or Xen Project throughout the
+document (except in the history)</li>
+<li>Refer to sub-projects and teams instead of projects where
+appropriate</li>
+</ul>
+</li>
+<li><strong><a
+href="index.php?option=com_content&view=archive&year=2013&month
+=3">v1.2</a> May 2012:</strong> Minor changes
+<ul>
+<li>Fixed typo and ambiguity in the role of Project Lead.</li>
+<li>Added section on Conflict Resolution.</li>
+</ul>
+</li>
+<li><strong>v1.1 Oct 2011:</strong> Minor changes
+<ul>
+<li>Clarified the roles of Committer and Maintainer.</li>
+<li>Added Making Contributions which contains links to other documentation
+and highlights that Xen.org required a DCO for contributions since
+2005.</li>
+</ul>
+</li>
+<li><strong>v1.0 Jun 2011:</strong> Intial document approved</li>
+</ul>
+</div>
projects / people / larsk / security-process.git / commitdiff