governance.html: from Lars (retry)

diff --git a/governance.html b/governance.html
index 085235a6ca839852d13f358880426a8d633e4fca..2144924f9a51cb7cf72dc1312fb2be16735fc360 100644 (file)
--- a/governance.html
+++ b/governance.html
@@ -1,536 +1,255 @@
-<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>
+<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>
 <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>
+    <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>
 </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>
+<p>
+    <a id="principles"></a>
+</p>

 <h2>Principles</h2>
 <h3>Openness</h3>
 <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>
+<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>
 <h3>Transparency</h3>

-<p>Project discussions, minutes, deliberations, project plans, plans for
-new features, and other artefacts are open, public, and easily
-accessible.</p>
+<p>Project discussions, minutes, deliberations, project plans, plans for new features, and other artefacts are open, public, and easily accessible.</p>

 <h3>Meritocracy</h3>
 <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>
+<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>
 <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>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>
 <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>
+    <li>+1 : a positive vote</li>
+    <li>0 : abstain, have no opinion</li>
+    <li>-1 : a negative vote</li>

 </ul>
 </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>
+<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>
 <h3>Conflict Resolution</h3>
 <h4>Refereeing</h4>

-<p>Sub-projects and teams hosted on&nbsp;Xenproject.org&nbsp;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>
+<p>Sub-projects and teams hosted on&nbsp;Xenproject.org&nbsp;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>
 <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&amp;view=article&amp;id=122:join-as-a-co
-rporate-member&amp;catid=83:about&amp;Itemid=717">Xen Project Advisory
-Board</a> will break the tie through a casting vote.</p>
-<p><a id="roles"></a></p>
+<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&amp;view=article&amp;id=122:join-as-a-corporate-member&amp;catid=83:about&amp;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>
 <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>
+<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>
 <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&amp;view=article&amp;id=82:xen-hyperviso
-r&amp;catid=80:developers&amp;Itemid=484">Hypervisor team portal</a>).</p>
+<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&amp;view=article&amp;id=82:xen-hypervisor&amp;catid=80:developers&amp;Itemid=484">Hypervisor team portal</a>).</p>

 <h3>Sub-projects and Teams</h3>
 <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&amp;view=article&amp;id=80:projects&amp;
-catid=80:developers&amp;Itemid=482">team portal</a> on Xenproject.org.</p>
+<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&amp;view=article&amp;id=80:projects&amp;catid=80:developers&amp;Itemid=482">team portal</a> on Xenproject.org.</p>

 <h3>Project Lead</h3>
 <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>
+<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>
 <h3>Xen Project Advisory Board</h3>

-<p>The <a 
-href="index.php?option=com_content&amp;view=article&amp;id=122:join-as-a-co
-rporate-member&amp;catid=83:about&amp;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>
+<p>The <a href="index.php?option=com_content&amp;view=article&amp;id=122:join-as-a-corporate-member&amp;catid=83:about&amp;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>
 <h3>The Linux Foundation</h3>

-<p>The Xen Project is a <a
-href="index.php?option=com_content&amp;view=article&amp;id=101:linux-founda
-tion&amp;catid=85:about-xen&amp;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>
+<p>The Xen Project is a <a href="index.php?option=com_content&amp;view=article&amp;id=101:linux-foundation&amp;catid=85:about-xen&amp;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>
 <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>
+<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>
 <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>
+<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>
 <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>
+<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>
 <ul>

-<li><a 
-href="index.php?option=com_content&amp;view=article&amp;id=130:contribution
--guidelines&amp;catid=82:help&amp;Itemid=742">Contribution
-Guidelines</a></li>
+    <li><a href="index.php?option=com_content&amp;view=article&amp;id=130:contribution-guidelines&amp;catid=82:help&amp;Itemid=742">Contribution Guidelines</a></li>

 </ul>
 <h2>Elections and Formal Votes</h2>
 <h3>Maintainer Elections</h3>
 </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>
+<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>
 <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>
+    <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>
 </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>
+<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>
 <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>
+    <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>
 </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>
+<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>
 <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&amp;view=article&amp;id=97:security-poli
-cy&amp;catid=85:about-xen&amp;Itemid=521">Security Policy</a> which
-applies to the <a 
-href="index.php?option=com_content&amp;view=article&amp;id=82:xen-hyperviso
-r&amp;catid=80:developers&amp;Itemid=484">Hypervisor Project</a> only.
-Examples of global scope are changes to this document or votes outlined in
-the Project Governance.</p>
+<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&amp;view=article&amp;id=97:security-policy&amp;catid=85:about-xen&amp;Itemid=521">Security Policy</a> which applies to the <a href="index.php?option=com_content&amp;view=article&amp;id=82:xen-hypervisor&amp;catid=80:developers&amp;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>
 <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>
+    <a id="project-governance"></a>

 </p>
 </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>
 <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&nbsp;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><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&nbsp;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>
 <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>
+    <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>
 </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>
+<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>
 <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>
+<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>
 <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>
+    <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>
 </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>
+<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>
 <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&nbsp;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&nbsp;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>
+    <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&nbsp;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&nbsp;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>
 </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>
+<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>
 <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>
+    <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>
 </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 &amp; Roles" of&nbsp;
-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>
+<p>The purpose of the incubation phase is for a project to show that it is gathering momentum and adheres to the "Principles &amp; Roles" of&nbsp; 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>
 <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>
+<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>
 <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>
+<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>
 <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>
+    <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>
 </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>
+    <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>
 </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>
+<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>
 <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>
+    <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>
 </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>
+<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>
 <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>
+    <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>
 </ul>

-<p>In cases where the project has delivered code into other sub-projects
-hosted on Xenproject.org, the code will be</p>
+<p>In cases where the project has delivered code into other sub-projects hosted on Xenproject.org, the code will be</p>

 <ul>
 <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>
+    <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>
 </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>
+<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>
 <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>
+<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">
 <h2>Change History</h2>
 <div class="box-note">

-<ul>
-<li><strong><strong>v2.1 May 2016:</strong></strong>&nbsp;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&amp;view=archive&amp;year=2013&amp;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>
+    <ul>
+        <li><strong><strong>v2.1 May 2016:</strong></strong>&nbsp;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&amp;view=archive&amp;year=2013&amp;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>
\ No newline at end of file