<h1>Xen.org Project Governance</h1>
<p>This document has come in effect in June 2011 and will be reviewed periodically (see revision sections).</p>
+ <a id="goals"> </a>
<h2>Goals</h2>
<p>The goals of Xen.org Project Governance are to:</p>
<ul>
<li>Encourage Xen related projects to be hosted on Xen.org rather than going elsewhere</li>
<li>Set clear expectations to vendors, upstream and downstream projects and community members</li>
</ul>
+ <a id="principles"> </a>
<h2>Principles</h2>
<h3>Openness</h3>
<p>Xen.org is open to all and provides the same opportunity to all. Everyone participates with the same rules.
</ul>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.</p>
+ <a id="conflict"> </a>
<h3>Conflict Resolution</h3>
<h4>Refereeing</h4>
<p>Xen.org projects are not democracies but meritocracies. In situations where there is disagreement on issues related to the day-to-day running of the project,
<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
chairman of Xen.org will break the tie through a casting vote.</p>
+ <a id="roles"> </a>
<h2>Roles</h2>
<h3>Maintainer</h3>
<p>Maintainers own one or several components in the Xen tree. A maintainer reviews and approves changes that affect their components.
or committer of a mature project, a member of the Xen.org advisory board or the community manager. This ensures that a distinguished
community member supports the idea behind the project.</p>
+ <a id="contributions"> </a>
<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
<br>
</p>
+ <a id="elections"> </a>
<h2>Elections</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>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>
+ <a id="project"> </a>
<h2>Project Governance</h2>
<h3>Basic Project Life Cycle</h3>
<p>The proposal is to follow a simple basic flow:</p>
</ul>
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.</p>
+ <a id="project.requests"> </a>
<h3>Requesting Reviews, Reviews and Voting</h3>
<p><b>Requesting Reviews:</b> 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.org community manager. The community
<p><b>Voting:</b> The community manager arranges a timed private vote as outlined above (voting should be open for a minimum of a week). Any maintainer of a mature
project and the Xen.org community manager is allowed to vote. Voting follows the conventions as laid out in "Principle: Consensus Decision Making".</p>
+ <a id="project.forming"> </a>
<h3>Forming a Project</h3>
<p>Requirements for forming a Xen.org project:
<ul>
<li>A rough plan on how to get through the Incubation phase </li>
</ul></p>
+ <a id="project.proposal"> </a>
<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:
<li>A wiki page on <a href="http://wiki.xen.org">wiki.xen.org</a> (this is expected to be maintained by the project lead)</li>
</ul></p>
+ <a id="project.incubation"> </a>
<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 Xen.org
projects. 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
that the project lead gives at least quarterly updates on the Xen.org blog on how the project is doing.</p>
<p>Xen.org will provide support to incubating projects. The project lead will work closely with the Xen.org community manager as well as with the project mentor.</p>
+ <a id="project.archivation"> </a>
<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>
<li>It promotes itself at events and on the blog</li>
</ul></p>
+ <a id="project.mature"> </a>
<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.
Xen.org and the community manager will help organize events, provide opportunities for the project to get new contributors and build a community,
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>
+ <a id="project.archivation.review"> </a>
<h3>Archivation Review </h3>
<p>These can happen in a number of situations:
<ul>
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>
+ <a id="project.archived.projects"> </a>
<h3>Archived Projects</h3>
<p>When a project is archived the following happens:
<ul>
release (it should however give users sufficient time to adapt)</li>
</ul></p>
+ <a id="project.exceptions"> </a>
<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