<li><a href="#roles-global">Xen Project Wide Roles</a></li>
<li><a href="#roles-local">Project Team Roles</a></li>
<li><a href="#contributions">Making Contributions</a></li>
- <li><a href="#decisions">Decision Making, Conflict Resolution, Role Nominations and
+ <li><a href="#decisions">Decision Making, Conflict Resolution, Role Nominations and
Elections</a></li>
- <li><a href="#formal-votes">Formal Votes</a></li>
+ <li><a href="#project-decisions">Project Wide Decision Making</a></li>
<li><a href="#project-governance">Project Governance</a></li>
+ <li><a href="#specialisations">Per Sub-Project Governance Specialisations</a></li>
</ul>
<p>
<a id="goals"></a>
<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>Local Decision Making</h3>
<pre>
-------------------------------------------------------------------------------------
-I moved the "Roles" section up and split it into two sections with unmodified content
-- Xen Project Wide Roles
-- Project Team Roles
+This is a little clumsy: maybe someone can come up with a better definition
-------------------------------------------------------------------------------------
</pre>
+<p>The Xen Project consists of a number of sub-projects: each sub-project
+ makes technical and other decisions that solely affect it locally.</p>
<p>
<a id="roles"></a>
<a id="roles-global"></a>
</p>
<h2>Xen Project Wide Roles</h2>
-<pre>
--------------------------------------------------------------------------------------
-MINOR ISSUES TO BE ADDRESSED LATER:
-- Sub-projects and Teams would benefit from some forward references to highlight the
- difference between incubation mature projects.
-- Also we should clarify what assets a sub-project owns.
-- Add the role of Community Manager as it used throughout the document
--------------------------------------------------------------------------------------
-</pre>
<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
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="/developers/teams.html">team
- portal</a> on Xenproject.org.</p>
+ portal</a> on Xenproject.org.
+ Sub-projects own and are responsible for a collection of source repositories
+ and other resources (e.g. test infrastructure, CI infrastructure, ...),
+ which we call <b>sub-project assets</b> (or team assets) in this document.</p>
+<p>Sub-projects can either be <b>incubation projects</b> or <b>mature projects</b>
+ as outlined in <a href="#project-governance">Basic Project Life Cycle</a>.
+ In line with the meritocratic principle, mature projects have more influence
+ than incubation projects, on <a href="#project-decisions">project wide
+ decisions</a>.</p>
+<h3>Community Manager</h3>
+<p>The Xen Project has a community manager, whose primary role it is to
+ support the entire Xen Project Community.</p>
<h3>Xen Project Advisory Board</h3>
<p>The <a href="/join.html">Xen Project Advisory Board</a> consists of
members who are committed to steering the project to advance
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>
+ to support the creation of the new project. A sponsor can be a member
+ of the project leadership team 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>
<a id="roles-local"></a>
</p>
<h2>Project Team Roles</h2>
+ <p>Sub-projects or teams are driven by the people who volunteer for the
+ job. This functions well for most cases. This section lists the main
+ roles which projects use. This section lists the default roles, which
+ are based on how the Hypervisor project operates. Sub-projects can
+ deviate from the default, but are required to document deviations from
+ the default and link to it from this <a href="#specialisation">document</a>.
+ The only exception is that each project is required to have a project
+ leadership team, as without it, the project will not be able to function.</p>
+<p>The following table lists how each project uses these roles. Note that
+ <b>incubation projects</b> have more flexibility in experimenting with
+ roles that work for them, but need to define specialistions before
+ they can <b>mature</b>.</p>
+<table class="zebra">
+ <tbody>
+ <tr>
+ <td width="20%"><b>Project</b></td>
+ <td width="12%"><b>Mature</b></td>
+ <td width="12%"><b>Maintainers</b></td>
+ <td width="12%"><b>Committers</b></td>
+ <td width="12%"><b>Security Team</b></td>
+ <td width="32%"><b>Leadership Team</b></td>
+ </tr>
+ <tr>
+ <td><b>Hypervisor</b></td>
+ <td>YES</td>
+ <td>YES</td>
+ <td>YES</td>
+ <td>YES</td>
+ <td>Committers and Release Manager, without a Project Lead</td>
+ </tr>
+ <tr>
+ <td><b>Windows Drivers</b></td>
+ <td>NO</td>
+ <td>YES</td>
+ <td>YES</td>
+ <td>NO</td>
+ <td>Committers, with a Project Lead</td>
+ </tr>
+ <tr>
+ <td><b>XAPI</b></td>
+ <td>YES</td>
+ <td>YES</td>
+ <td>YES</td>
+ <td>NO</td>
+ <td>Committers, with a Project Lead</td>
+ </tr>
+ </tbody>
+</table>
+<h3>Maintainers</h3>
+<p>Maintainers own one or several components in the sub-projects source
+ tree(s). 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 each code repository that
+ the project owns.</p>
+<p>Larger sub-projects such as the Hypervisor may have special maintainer
+ roles such as a release manager and stable branch maintainers. In addition,
+ larger projects may award different maintainers different levels of
+ influence. Any specialisations and implications are documented in the
+ respective MAINTAINERS file.</p>
<pre>
-------------------------------------------------------------------------------------
-ISSUES TO BE ADDRESSED LATER:
-- Fix minor Inaccuracies and Improvements
-- Allow for customization of roles by sub-projects (but this definition is the default)
-- Allow for Security Response Team
-- Allow for sub-projects to be lead by a Project Leadership Team (which may include a
- Project Lead)
+CONSISTENCY ISSUES that probably ought to be cleaned up at some point
+- The xen.git MAINTAINERS file does not list our release managers and
+ stable branch maintainers
+- We do have a number of repos without MAINTAINERS files, e.g. mini-os.git,
+ osstest.git
+- For projects with many repositories (e.g. XAPI and Mirage OS), using MAINTAINERS
+ files is not very practical. XAPI seems to sometimes use MAINTAINERS and README
+ files at other times. We may need a more central place to state roles.
-------------------------------------------------------------------------------------
</pre>
-<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
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="/developers/teams/hypervisor.html">Hypervisor team portal</a>).</p>
-<h3>Project Lead</h3>
+ <a href="/developers/teams/hypervisor.html">Hypervisor team portal</a>)
+ and/or in the projects MAINTAINERS files.</p>
+<h3>Security Response Team</h3>
+<p>Each sub-project may have a security response team, that is responsible
+ for receiving, reviewing, and responding to security incident reports
+ for the sub-projects assets according to its security response process
+ (e.g. <a href="/security-policy.html">Hypervisor Security Problem Response
+ Process</a>).</p>
+<h3>Project Leadership Team and 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>
+ Leadership Team. The leadership team is made up of distinguished community
+ members, but the exact composition may depend on the sub-project. For
+ example, in the case of the Hypervisor sub-project, all committers
+ and the release manager, are part of the leadership team. The leadership
+ team owns the sub-projects processes, the overall architecture and
+ all assets within the project and makes <a href="#decisions">sub-project
+ wide decisions</a> on behalf of its community.</p>
+<p>A sub-projects leadership team members are listed on the sub-project's
+ team portal (e.g. <a href="developers/teams/hypervisor.html">Hypervisor
+ team portal</a>).</p>
<pre>
-------------------------------------------------------------------------------------
-Moved this section
+CONSISTENCY ISSUES that probably ought to be cleaned up at some point
+- XAPI and Mirage OS ought to decide who their leadership team is
+ (I made some assumptions for now)
-------------------------------------------------------------------------------------
</pre>
+<p>The Leadership Team may elect a Project Lead who is also a member of
+ the Leadership Team. Project Leads are the public figurehead of the
+ project and are responsible for the health of the project. Project
+ Leads can also act as <a href="#conflict">referees</a> should the Project
+ Leadership Team become paralysed.</p>
<p>
<a id="contributions"></a>
</p>
documents:</p>
<ul>
<li><a href="/help/contribution-guidelines.html">Contribution Guidelines</a></li>
+ <li><a href="#RTC">Review Then Commit Policy</a></li>
</ul>
+<p>
+ <a id="decisions"></a>
+</p>
+<h2>Decision Making, Conflict Resolution, Role Nominations and Elections</h2>
+<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. This section lists the main mechanisms by which
+ projects make decisions. This section lists the default mode of operation,
+ which is based on how the Hypervisor project operates. Sub-projects
+ can deviate from the default, but are required to document deviations
+ from the default and link to it from this <a href="#specialisation">document</a>.
+ The only exception is that each project is required to adhere to the
+ <b>Review Then Commit Policy</b>, <b>Leadership Team Decisions</b> and
+ <b>Conflict Resolution</b>.</p>
<pre>
-------------------------------------------------------------------------------------
-Consolidated all Decision Making Related topics into one section
-- I changed the order of the sections from ...
- "Consensus Decision Making, Conflict Resolution, Elections and Formal Votes" to
- "Consensus Decision Making, Formal Votes, Conflict Resolution, Elections"
-- I changed header titles and fixed the headline
-
-Otherwise the relevant sections remain identical, with the exception of comment
-sections that I added, which highlight issues that are to be addressed.
+TODO, after this section is agreed, or mostly agreed
+- Add a table of the projects that states who adheres to the default
+- I believe that the Hypervisor, winPV and XAPI are likely to adhere to this section
-------------------------------------------------------------------------------------
</pre>
<p>
- <a id="decisions"></a>
+ <a id="RTC"></a>
</p>
-<h2>Decision Making, Conflict Resolution, Role Nominations and Elections</h2>
+<h3>Review Then Commit</h3>
+<p>The vast majority of technical decisions within the Xen Project are code
+ related decisions (e.g. patches and design documents), which determine
+ whether a specific change can be accepted into the code base. The default
+ decision making process is a review and commit process, which requires
+ that all changes receive explicit approval from respective code owners
+ (maintainers) before they are committed. The exact workflow and details
+ of this policy between sub-projects may differ and are documented in
+ one or several of the following places: MAINTAINERS/README/CONTRIBUTING
+ files in repositories and/or the sub-project team portal.</p>
+<p>
+ <a id="expressingopinion"></a>
+</p>
+<h3>Expressing Agreement and Disagreement</h3>
+<p>Within the community, we follow the following number notation to explicitly
+ express opinions on proposals, formal or informal votes.</p>
+<ul>
+ <li><b>+2</b> : I am happy with this proposal, and I will argue for it</li>
+ <li><b>+1</b> : I am happy with this proposal, but will not argue for it</li>
+ <li><b>0</b> : I have no opinion</li>
+ <li><b>-1</b> : I am not happy with this proposal, but will not argue against
+ it</li>
+ <li><b>-2</b> : I am not happy with this proposal, and I will argue against
+ it</li>
+</ul>
+<p>A <b>-2</b> should include an alternative proposal or a detailed explanation
+ of the reasons for the negative opinion. A <b>+2</b> should include
+ reasons for the positive opinion.</p>
+<p>How we tally results and their implications depend on the context in
+ which is is used and are marked with <u>Passed/Failed:</u> in one of
+ the following sections:</p>
+<ul>
+ <li><a href="#lazyconsensus">Lazy Consensus</a></li>
+ <li><a href="#leadership">Leadership Team Decisions</a></li>
+ <li><a href="#project-decisions">Project Wide Decision Making</a></li>
+</ul>
+<p>
+ <a id="lazyconsensus"></a>
+</p>
+<h3>Lazy Consensus</h3>
+<p>Lazy Consensus is a useful technique to make decisions for specific proposals
+ which are not covered by the Review Then Commit Policy or do not require
+ a more formal decison (see below). Lazy Consensus is extremely useful,
+ when you don't anticipate any objections, or to gage whether there
+ are objections to a proposal. To make use of it, post something like
+ the following on the project's mailing list (or some other communication
+ channel):</p>
<pre>
-------------------------------------------------------------------------------------
-ISSUES TO BE ADDRESSED LATER:
-- Add a pre-amble explaining the different decision making mechanisms and when they
- apply
-- Add a section about review and commit, which is the primary means of making
- code related decisions
+Should we set a fixed time-frame? If so what?
-------------------------------------------------------------------------------------
</pre>
-<h3>Consensus Decision Making</h3>
+<blockquote>I am assuming we are agreed on X and am going to assume lazy consensus:
+if there are no objections within the next seven days.</blockquote>
+<p>You should however ensure that all relevant stake-holders which may object
+ are explicitly CC'ed, such as relevant maintainers or committers, ensure
+ that <b>lazy consensus</b> is in the body of your message (this helps
+ set up mail filters) and choose a reasonable time-frame. If it is unclear
+ who the relevant stake-holders are, the project leadership can nominate
+ a group of stake-holders to decide, or may choose to own the decision
+ collectively and resolve it.</p>
+<p>Objections by stake-holders should be expressed using the
+ <a href="#expressingopinion">conventions above</a> to make disagreements easily
+ identifiable.</p>
+<p><u>Passed/Failed:</u></p>
+ <ul>
+ <li>Failed: A single <b>-2</b> by a stake-holder whose approval is necessary</li>
+ <li>Failed: <b>-1</b>'s by all stake-holder whose approval is necessary</li>
<pre>
-------------------------------------------------------------------------------------
-ISSUES TO BE ADDRESSED LATER:
-- The "Consensus Decision Making" section is totally wrong. It does not describe
- "Lazy Consensus"
+We could add other conditions, but I don't think this is necessary
-------------------------------------------------------------------------------------
</pre>
-<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>
+ <li>Passed: In all other situations</li>
+ </ul>
<pre>
-------------------------------------------------------------------------------------
-- Introduce -2 to +2 voting under a new section
+I added the following section, as we did have real cases like this in the past.
+In particular an issue may not have been highlighted to all the relevant people in
+time.
-------------------------------------------------------------------------------------
</pre>
-<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.</p>
+<p>It can only be overturned if the project leadership agrees collectively,
+ that the decision is too important to be settled by lazy consensus.
+ In situations where a proposal is failed, an alternative solution needs
+ to be found, or if a decision is formally challenged, <a href="#conflict">conflict resolution mechanisms</a> may need to be used to resolve the situation.</p>
<p>
- <a id="conflict"> </a>
+ <a id="informal"></a>
</p>
-<h3>Conflict Resolution</h3>
+<h3>Informal Votes or Surveys</h3>
<pre>
-------------------------------------------------------------------------------------
-ISSUES TO BE ADDRESSED LATER:
-- Generalise refereeing in terms of Project Leadership instead of specific roles
-- Also some examples for sPecific situations that have happened in the past may be
- useful
+RATIONALE for the following section:
+in practice, we have always operated this way. We did this, when we introduced the
+security vulnerability process and for other controversial changes.
+-------------------------------------------------------------------------------------
+</pre>
+<p>Generally the Xen Project community tries to achieve consensus on most
+ issues. In situations where several concrete options are possible,
+ community members may organize an informal vote on the different proposals
+ and use the <a href="#expressingopinion">conventions above</a> to identify
+ the strongest proposal. Once the strongest candidate has been identified,
+ <a href="#lazyconsensus">lazy consensus</a> could be used to close
+ the discussion. In some situation, a specific survey may need to be
+ created, to help identify gaging consensus on specific issues. For
+ informal votes and surveys, we do not prescribe specific rules, as
+ they are non-binding: it is up to the organizer of an informal vote
+ or survey to interpret the result and explain it to the community.
+ If the vote/survey relates to an area that is owned by the project
+ leadership, the project leadership has to formally confirm the decision.</p>
+<p>Note that informal votes amongst a small set of stake-holders that disagree
+ on a position during technical disagreements in code, design reviews
+ and other discussions can be useful. In technical discussions it is
+ not always clear how strong agreement or disagreement on a specific
+ issue is. Using the <a href="#expressingopinion">conventions above</a>,
+ can help differentiate between minor and major disagreements and reduce
+ the time a discussions continues unnecessarily. This is true in particular
+ for cases, where several maintainers may need to agree to a proposal.</p>
+<p>When having an informal vote or survey, they creator should consider
+ whether conducting a vote or survey in public, may be divisive and
+ damaging for the community. In such cases, the vote/survey should be
+ conducted anonomously.</p>
+<p>
+ <a id="leadership"></a>
+</p>
+<pre>
+-------------------------------------------------------------------------------------
+The following section represents the most significant change to the governance. In
+the original governance document, we had one way of making project-local decisions
+through a formal vote on proposals by maintainers. Unfortunately, in the original
+governance document, tallying the vote is not specified. However, in the general
+section about how we make decisions, we essentially say that decisions in general
+only hold, if there are no objections (vetos). As some people stated in prior
+discussion this gets as to "a UN-style model that requires unanimity".
+
+If we end up with disagreements, we then have conflict resolution mechanisms, which
+require a simple majority by committers.
+
+This raises the question, why we don't go for a more unified approach for decisions,
+that does not require two stages. In a number of previous discussions on xen-devel@
+it was proposed by several committers, that a majority based approach, with more than
+a simple majority as requirement for making decisions (e.g. 2/3rds or 75%) may be
+more desirable.
+
+This section attempts to
+- optimise, consolidate and clarify formal decision making
+- in particular in situations where it is not clear who owns a decision
+- and use the same decision making mechanism for *all* types of decisions that
+ cannot be resolved by RTC and Lazy Consensus
+- The exception is Project Wide Decision Making
-------------------------------------------------------------------------------------
</pre>
-<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="/join.html">Xen Project Advisory Board</a> will break
- the tie through a casting vote.</p>
+<h3>Leadership Team Decisions</h3>
+<p>Each sub-project has a leadership team, which is typically made up of
+ the most senior and influential developers within the sub-project (e.g.
+ the project's committers). The project leadership team owns decisions,
+ such as:</p>
+<ul>
+ <li>Sub-project wide policy decisions (e.g. policies, procedures and processes
+ whose scope is specific to the sub-projects). This includes deviations
+ from project global governance, where permissible.</li>
+ <li>Decisions related to sub-project assets that are not clearly owned
+ (e.g. unowned code, project wide assets such as test infrastructure,
+ etc.).</li>
+ <li>Decisions related to nominating and confirming leadership roles within
+ the sub-project. This includes <a href="#elections">decisions to creating
+ and filling specialised new roles</a>, such as release managers or similar,
+ including their scope and set of responsibilities.</li>
+ <li>Resolving <a href="#conflict">conflicts</a> within the sub-project
+ that cannot otherwise be resolved.</li>
+</ul>
+<p>Leadership team decisions can be made in private (e.g. a private IRC
+ meeting, on a private mailing list, through a private vote) or on a
+ public mailing list using <a href="#expressingopinion">decision making
+ conventions</a>. If a decision is made in private, the outcome must be
+ summarized in terms of number of votes in favour or against on a public
+ mailing list. Decisions should <b>not</b> generally be made in an anonymous
+ vote, unless there is a good reason to do so. For example, if the decision
+ may be divisive and damage the cohesion of the leadership team, an
+ anonymous vote is preferred. In such cases, the leadersheap team, can
+ ask the the community manager, to arrange an anonymous vote on behalf
+ of the leadership team.</p>
<pre>
-------------------------------------------------------------------------------------
-Changed headline structure: h2 to h3
-Removed Formal Votes from headline as it has been moved into a separate section
+The exact majority needed is up for discussion: 2/3rd majority is just a stake
+in the ground. Also, I think the differentiation between active and inactive
+leadership team members is a little clumsy and may not be necessary (see discussion
+below).
-------------------------------------------------------------------------------------
</pre>
+<p>Decisions (also called Resolutions) require a <b>2/3rd</b> majority amongst
+ active leadership team members. If a leadership team member has been
+ inactive for more than two months (i.e. the member has not engaged
+ with the community or leadership team for two months or more), the
+ team member is not considered to be part of the leadership team.
+ This avoids paralysis within the leadership team, if leadership team
+ members dissappear.</p>
+<p>Leadership team decisions normally have to be made actively: in other
+ words each team member has to cast a vote <b>explicitly</b> expressing
+ their opinion. The only exception are face-2-face or on-line meetings
+ with a quorum of <b>2/3rd</b> of active leadership team members present
+ at the meeting: in such cases a meeting chair is required who calls
+ for decision on a resolution and asks for objections. This allows to
+ conduct meetings more quickly.</p>
+<p><u>Passed/Failed Resolutions:</u></p>
+<ul>
+ <li>TODO</li>
+</ul>
+<pre>
+-------------------------------------------------------------------------------------
+We should discuss the exact mechanism by which we tally the votes
+
+Let me express this as an algorithm.
+
+ treshhold=2/3;
+ active='number of active members'; (7 for the Hypervisor project; IanC is inactive)
+ favour='number of +1 and +2 votes'
+ against='number of -1 and -2 votes'
+ strong-against='number -2 votes'; just added this as a sanity check
+
+One open question is what to do with 0-votes. We could introduce a rule discounting
+0 votes (let's call it 0-rule). If someone votes 0, we assume they really don't care
+about the outcome and are considered inactive for the purpose of the vote.
+
+In that case:
+
+ active -= 0-votes;
+
+Without the 0-rule:
+- to pass: favour/active >= treshhold
+ to pass: with active==7, favour >= 5
+ in other words, 3 (0,-1,-2)-votes block the proposal as we cant achieve favour>=5
+
+With the 0-rule, let's consider 1, 2 or 3 0-votes
+1=>6: to pass: favour >=4
+ in other words, 3 (-1,-2)-votes block the proposal
+2=>5: to pass: favour >=4
+ in other words, 2 (-1,-2)-vote blocks the proposal
+3=>4: to pass: favour >=3
+ in other words, 2 (-1,-2)-vote blocks the proposal
+
+Looking at the arithmetic, it does probably make sense to go for the 0-rule. If we
+do, there ought to be more votes in favour of a proposal, than 0-votes.
+
+On the other hand, not having the 0-rule forces everyone to form an opinion,
+otherise we will find it hard to make decisions. But in some cases, forming an
+opinion costs significant mental capacity.
+
+It would also allow us to remove the complexity of differentiating between
+active and non-active leadership team members by assuming that no vote, equals
+a "0" vote.
+
+Opinions?
+
+The other question is whether to treat -2-votes different than -1-votes. We could
+say there should not be more than 20% -2-votes. That would mean that
+
+Without the 0-rule:
+2 -2-votes would block a proposal (instead of 3 (0,-1,-2)-votes)
+
+With the 0-rule
+1=>6: 2 -2-votes would block a proposal
+2=>5: 1 -2-votes would block a proposal
+3=>4: 1 -2-votes would block a proposal
+
+This doesn't seem to make a difference big enough to grant the extra complexity.
+
+Opinions?
+
+-------------------------------------------------------------------------------------
+</pre>
+<p>
+ <a id="conflict"> </a>
+</p>
+<h3>Conflict Resolution</h3>
+<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, the <a href="#leadership">project
+ leadership team</a> is expected to act as referee and make a decision on behalf
+ of the community. Projects leadership teams can choose to delegate entire
+ classes of conflict resolution issues to community members and/or the
+ project lead (e.g. the project can choose to delegate refereeing on
+ committer disagreements to the project lead; or it could choose a specific
+ committer to always act as referee amongst a group of committers).
+ Any such delegation needs to be approved as normal and has to be documented.</p>
+<p>Should a project leadership team become dysfunctional or paralysed,
+ the project leadership team or project lead should work with the community
+ manager or advisory board to find a way forward.</p>
+<p>In situations where there is significant disagreement between sub-projects,
+ the issue is deferred to the <a href="/join.html">Xen Project Advisory Board</a>.</p>
+<pre>
+-------------------------------------------------------------------------------------
+The entire last resourt section goes, because it is essentially not needed any more,
+as the responsibility has been moved to the project leadership, which is now making
+majority based decisions.
+-------------------------------------------------------------------------------------
+</pre>
+<p>
+ <a id="elections"> </a>
+</p>
<h3>Elections</h3>
<h4>Maintainer Elections</h4>
-<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 existing maintainers 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
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>
+ the normal decision making process. If there is disagreement or doubt,
+ the decision is handled by the project leadership.</li>
</ul>
-<h4>Committer Elections</h4>
+<h4>Committer, Security Team Member and other Project Leadership Elections</h4>
<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>
+ through election be promoted to Committer, Security Team Member or
+ Project Leadership (if not covered otherwise). 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
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>
+ outlined earlier. In other words, the decision is delegated to the
+ <a href="#leadership">project leadership team</a>.</li>
</ul>
<h4>Project Lead Elections</h4>
-<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>Projects which have a project lead, should vote for a project lead in
+ an anonymous vote amongst the project leadership.</p>
<p>
+ <a id="voting"></a>
<a id="formal-votes"></a>
+ <a id="project-decisions"></a>
</p>
-<h2>Formal Votes</h2>
-<pre>
--------------------------------------------------------------------------------------
-ISSUES TO BE ADDRESSED LATER:
-- Local votes should be handled elsewhere: this section should only cover global
- decision making
-- Better specify scope : when are Formal Votes applicable
-- In fact we do not have any clear rules for tallying votes (do votes have to be
- unanimous or not)
-- Note that the voting eligibility is maintainers? Do we want to retain this?
- I assume NO, as in practive we never did this.
--------------------------------------------------------------------------------------
-</pre>
-<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="/security-policy.html">Security Policy</a>
- which applies to the <a href="/developers/teams/hypervisor.html">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>
+<h3>Project Wide Decision Making</h3>
+<p>Project wide decisions are made through <b>formal global votes</b> and
+ are conducted in rare circumstances only, following the principle of
+ <a href="#values">local decision making</a>. Global votes are only
+ needed, when all sub-projects hosted on Xenproject.org are affected.
+ This is true, only for:</p>
+<ul>
+ <li>Specific votes on creating, graduating, completing/archiving of sub-projects
+ as outlined in <a href="#project-governance">project governance</a>.</li>
+ <li>Changes to this document, where sub-projects cannot specialise. In
+ particular the sections: <a href="#goals">goals</a>,
+ <a href="#principles">principles</a>,
+ <a href="#project-decisions">project wide decision making</a> and
+ <a href="#project-governance">project governance</a> (and small parts
+ of <a href="#roles-global">Xen Project wide roles</a>,
+ <a href="#roles-local">project team roles</a> and
+ <a href="#decisions">decision making</a> that are needed for
+ project governance or <b>apply to all sub-projects</b> as stated
+ in those sections).</li>
+ <li>Changes to this document where sub-projects can specialise require
+ at least one mature project other than the Hypervisor project to
+ be impacted significantly by the change. The sections in question,
+ are <a href="#roles-local">project team roles</a> and
+ <a href="#decisions">decision making</a>.
+ These sections define the <b>gold standard</b> of how the original
+ Hypervisor Project operates. In other cases, the Hypervisor project
+ leadership team can agree changes to these sections, as they are
+ essentially reference definitions. Other sub-projects have to be
+ consulted, and have to be given time to adapt to changes.</li>
+ <li>Changes to existing global namespace policies (e.g.
+ <a href="/help/mailing-list/100-misc/139-mailing-list-conventions.html">
+ Mailing List Conventions</a>)
+ and creation of new project wide namespace policies.</li>
+ <li>Changes to the boundary of what policies are project local and global
+ decision: e.g. a decision to introduce a global Security Vulnerability
+ Response Process that affects all sub-projects.</li>
+ <li>Some sections of this document such as <a href="#roles-global">Xen
+ Project wide roles</a> and <a href="#contributions">making contributions</a>
+ <b>cannot be changed by the community</b> without obtaining additional
+ approval from the Advisory Board and/or the Linux Foundation, if these
+ conflict requirements that stem from being part of a Linux Foundation
+ Collaborative Project (e.g requiring a contributor license agreement).
+ Areas with such requirements cover trademarks, legal oversight, financial
+ oversight and project funding.</li>
+</ul>
+<p>Global votes are arranged by the community manager when needed (e.g.
+ for a project review or a global process change). Who exactly has input
+ on a proposal and can vote on it, depends on the type of change as
+ outlined below:</p>
+<table class="zebra">
+ <tbody>
+ <tr>
+ <td width="30%"><b>Proposal</b></td>
+ <td width="35%"><b>Who reviews?</b></td>
+ <td width="35%"><b>Who votes?</b></td>
+ </tr>
+ <tr>
+ <td>Creating, graduating, completing/archiving of sub-projects</td>
+ <td>Members of developer mailing lists of qualifying projects</td>
+ <td>Leadership teams of <b>mature</b> sub-projects, with the exception
+ of the project which is being reviewed (e.g. for an archivation
+ review, the leadership team of the project under review, cannot
+ vote).</td>
+ </tr>
+ <tr>
+ <td>Global Process Changes</td>
+ <td>Members of developer mailing lists of qualifying projects</td>
+ <td>Leadership teams of <b>mature</b> sub-projects, within the scope
+ described above.</td>
+ </tr>
+ </tbody>
+</table>
<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>
+ form that keeps auditable and tamper proof records) must be used.</p>
+<p>Voting is conducted <b>per project</b> in line with the following rules:</p>
+<ul>
+ <li>Each qualifying project's vote is counted per project and then aggregated
+ as outlined below.</li>
+ <li>Project leadership team members vote for or against a proposal (there
+ is no differentiation between <b>-1</b>/<b>-2</b> and <b>+1</b>/<b>+2</b>).
+ A <b>0</b> vote is not counted as a valid vote.</li>
+ <li>A <b>quorum of more than 50%</b> of each project's leadership team
+ members is required. In other words: if more than half of a project's
+ leadership team members do not vote or abstain, the entire sub-project's
+ vote is not counted. This avoids situations where only a minority
+ of leadership team members votes, which would skew the overall result.
+ If it becomes clear, that a sub-project is not likely to meet the
+ quorum, the voting deadline can be extended by the communiuty manager.</li>
+</ul>
+<p><u>Passed/Failed Resolutions:</u></p>
+<ul>
+ <li>If none of the qualifying projects achieve a quorum, the change cannot
+ hold. In that case, we consider that there is not enough momentum
+ behind a change.</li>
+ <li>For each qualifying project with a quorum, the percentage of votes
+ in favour and against is calculated (e.g. if 5 people voted in favour,
+ 2 against and 1 abstains, the share is 5/7th and 2/7th respectively).</li>
+ <li>Votes in favour are averaged as percentages across all projects (say
+ we have per project figures of 50%, 80%, 70% in favour, then the
+ total vote in favour is 66.67%).
+ <li>If the total vote is more than 2/3rds in favour, the proposal passes.
+ Otherwise it fails.</li>
+</ul>
<p>
<a id="project-governance"></a>
</p>
-------------------------------------------------------------------------------------
ISSUES TO BE ADDRESSED LATER:
- Verify terminology in light of changes above
+- But let's agree the previous set of sections first
-------------------------------------------------------------------------------------
</pre>
<h2>Project Governance</h2>
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>
+ 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
</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
+ 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
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>
+<h4>Incubation Projects without Project Lead</h4>
+<p>Projects which lose their project lead during the incubation phase, and
+ do not have a working project leadership team, are at risk of failing.
+ Should this occur, the project's maintainer or committer community
+ should nominate a new project lead and follow the election process
+ as outlined in <a href="#elections">elections</a>.</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>
+ and will consider archiving the project.</p>
+<h4>Projects without functional Project Leadership Team</h4>
+<p>Projects which lose their project leadership team, or whose project leadership
+ team is too small to function, are at risk of failing. A project leadership
+ team should be of sufficient size to manage the project. Should this
+ occur, the project's maintainer or committer community should nominate
+ new leadership team members and follow the election process as outlined
+ in <a href="#elections">elections</a>.</p>
+<p>If the community cannot create a functional leadership team, we assume
+ that the project does not have enough momentum and will consider archiving
+ the project.</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>v3.0 July 2016:</strong> TODO: Add real changelog in main patch</li>
- <li><strong>v2.1 May 2016:</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>v3.0 July 2016:</strong> Refactored document. Otherwise
+ significant changes to decision making, in the following areas
+ <ul>
+ <li>Split roles into project wide and sub-project specific roles.</li>
+ <li>Added +2 ... -2 scheme for votes.</li>
+ <li>Clarified lazy consensus.</li>
+ <li>Added Project Team Leadership role and Decision making.</li>
+ <li>Changed Project Wide Decision making.</li>
+ <li>Clarified scope of Decision making</li>
+ <li>Modified sections which have dependencies on changes above.</li>
+ </ul>
+ </li>
+ <li><strong>v2.1 May 2016:</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>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
+ <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>
since 2005.</li>
</ul>
</li>
- <li><strong>v1.0 Jun 2011:</strong> Intial document approved</li>
+ <li><strong>v1.0 Jun 2011:</strong> Initial document approved</li>
</ul>
-</div>
+</div>
\ No newline at end of file
projects / people / larsk / security-process.git / commitdiff