| Message ID | 1479903646-6772-4-git-send-email-lars.kurth@citrix.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, 23 Nov 2016, Lars Kurth wrote: > List of changes > - Added Goal: Local Decision Making > - Split roles into project wide and sub-project specific roles > - Added new roles: Community Manager, Security Response Team, Leadership Team > - Added RTC Policy > - Added +2 ... -2 scheme for expressing opinions more clearly > - Clarified lazy consensus / lazy voting with examples > - Added Informal Votes or Surveys > - Added Project Team Leadership decisions (majority vote, non-monotonicity) > - Clarified and Adapted Conflict Resolution to previous changes > - Updated Elections to cover new roles and terminology > - Changed Project Wide Decision making (per project, non-monotonicity) > - Clarified scope of Decision making > - Added section on Community Decisions with Funding and Legal Implications > - Modified all other sections which have dependencies on changes above > - Added Per Sub-Project Governance Specialisation > - Fixed various typos > - Fixed changelog > > Signed-off-by: Lars Kurth <lars.kurth@citrix.com> > --- > governance.pandoc | 628 ++++++++++++++++++++++++++++++++++++++++++------------ > 1 file changed, 496 insertions(+), 132 deletions(-) > > diff --git a/governance.pandoc b/governance.pandoc > index 2ce780c..188fa41 100644 > --- a/governance.pandoc > +++ b/governance.pandoc > @@ -1,5 +1,5 @@ > This document has come in effect in June 2011 and will be reviewed periodically > -(see revision sections). The last modification has been made in July 2016. > +(see revision sections). The last modification has been made in December 2016. > > Content > ------- > @@ -11,8 +11,10 @@ Content > - [Making Contributions](#contributions) > - [Decision Making, Conflict Resolution, Role Nominations and > Elections](#decisions) > -- [Formal Votes](#formal-votes) > +- [Project Wide Decision Making](#project-decisions) > +- [Community Decisions with Funding and Legal Implications](#funding-and-legal) > - [Project Governance](#project-governance) > +- [Per Sub-Project Governance Specialisations](#specialisations) > > Goals {#goals} > ----- > @@ -54,7 +56,12 @@ 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. > > -Xen Project Wide Roles {#roles-global} > +### Local Decision Making > + > +The Xen Project consists of a number of sub-projects: each sub-project makes > +technical and other decisions that solely affect it locally. > + > +Xen Project Wide Roles {#roles-global} > ---------------------- > > ### Sub-projects and Teams > @@ -64,9 +71,22 @@ the [Project Governance](#project-governance) (or Project Lifecycle) as > outlined in this document. Sub-projects (sometimes simply referred to as > projects) are run by individuals and are often referred to as teams to > highlight the collaborative nature of development. For example, each > -sub-project has a [team portal](/developers/teams.html) on Xenproject.org. > +sub-project has a [team portal](/developers/teams.html) 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 **sub-project assets** (or team assets) in this document. > + > +Sub-projects can either be **incubation projects** or **mature projects** as > +outlined in [Basic Project Life Cycle](#project-governance). In line with the > +meritocratic principle, mature projects have more influence than incubation > +projects, on [project wide decisions](#project-decisions). > + > +### Community Manager > > -### Xen Project Advisory Board > +The Xen Project has a community manager, whose primary role it is to support > +the entire Xen Project Community. > + > +### Xen Project Advisory Board {#roles-ab} > > The [Xen Project Advisory Board](/join.html) consists of members who are > committed to steering the project to advance its market and technical success, > @@ -76,7 +96,7 @@ shared project infrastructure, marketing and events, and managing the Xen > Project trademark. The Advisory Board leaves all technical decisions to the > open source meritocracy. > > -### The Linux Foundation > +### The Linux Foundation {#roles-lf} > > The Xen Project is a [Linux Foundation](/linux-foundation.html) Collaborative > Project. Collaborative Projects are independently funded software projects that > @@ -95,21 +115,48 @@ members or other distinguished community members. > ### Sponsor > > To form a new sub-project or team on Xenproject.org, we require a sponsor to > -support the creation of the new project. A sponsor can be a project lead or > -committer of a mature project, a member of the advisory board or the community > -manager. This ensures that a distinguished community member supports the idea > -behind the project. > +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. > > Project Team Roles {#roles-local} > ------------------ > > +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 > +[document](#specialisations). 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. > + > +The following table lists how each project uses these roles. Note that > +**incubation projects** have more flexibility in experimenting with roles that > +work for them, but need to define specializations before they can **mature**. > + > + --------------------- ------------ ----------------- ---------------- ------------------- -------------------------------------------------------- > + **Project** **Mature** **Maintainers** **Committers** **Security Team** **Leadership Team** > + **Hypervisor** YES YES YES YES Committers and Release Manager, without a Project Lead > + **Windows Drivers** NO YES YES NO Committers, with a Project Lead > + **XAPI** YES YES YES NO Committers, with a Project Lead > + --------------------- ------------ ----------------- ---------------- ------------------- -------------------------------------------------------- > + > ### Maintainers > > -Maintainers own one or several components in the Xen tree. A maintainer reviews > -and approves changes that affect their components. It is a maintainer's prime > -responsibility to review, comment on, co-ordinate and accept patches from other > -community member's and to maintain the design cohesion of their components. > -Maintainers are listed in a MAINTAINERS file in the root of the source tree. > +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. > + > +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. > > ### Committers > > @@ -119,17 +166,34 @@ applies changes that have been approved by the respective maintainer(s) to the > source tree. Due to their status in the community, committers can also act as > referees should disagreements amongst maintainers arise. Committers are listed > on the sub-project's team portal (e.g. [Hypervisor team > -portal](/developers/teams/hypervisor.html)). > +portal](/developers/teams/hypervisor.html)) and/or in the projects MAINTAINERS > +files. > > -### Project Lead > +### Security Response Team (short: Security Team) > > -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. > +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. > +[Hypervisor Security Problem Response Process](/security-policy.html)). > + > +### Project Leadership Team and Project Lead > + > +Sub-projects and teams hosted on Xenproject.org are managed by a Project > +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 [sub-project wide decisions](#decisions) on behalf of its > +community. > + > +A sub-projects leadership team members are listed on the sub-project's team > +portal (e.g. [Hypervisor team portal](developers/teams/hypervisor.html)). > + > +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 > +[referees](#conflict) should the Project Leadership Team become paralysed. > > Making Contributions {#contributions} > -------------------- > @@ -146,62 +210,253 @@ More information on making contributions can be found in the following > documents: > > - [Contribution Guidelines](/help/contribution-guidelines.html) > +- [Review Then Commit Policy](#RTC) > > -Decision Making, Conflict Resolution, Role Nominations and Elections > -{#decisions} > +Decision Making, Conflict Resolution, Role Nominations and Elections {#decisions} > -------------------------------------------------------------------- > > -### Consensus Decision Making > - > Sub-projects or teams hosted on Xenproject.org are normally auto-governing and > driven by the people who volunteer for the job. This functions well for most > -cases. When more formal decision making and coordination is required, decisions > -are taken with a lazy consensus approach: a few positive votes with no negative > -vote are enough to get going. > - > -Voting is done with numbers: > - > -- +1 : a positive vote > -- 0 : abstain, have no opinion > -- -1 : a negative vote > - > -A negative vote should include an alternative proposal or a detailed > -explanation of the reasons for the negative vote. The project community then > -tries to gather consensus on an alternative proposal that resolves the issue. > -In the great majority of cases, the concerns leading to the negative vote can > -be addressed. > - > -### Conflict Resolution > - > -#### Refereeing > +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 > +[document](#specialisation). The only exception is that each project is > +required to adhere to the **Review Then Commit Policy**, **Leadership Team > +Decisions** and **Conflict Resolution**. > + > +### Review Then Commit {#RTC} > + > +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. > + > +### Expressing Agreement and Disagreement {#expressingopinion} > + > +Within the community, we follow the following number notation to explicitly > +express opinions on proposals, formal or informal votes. > + > +- **+2** : I am happy with this proposal, and I will argue for it > +- **+1** : I am happy with this proposal, but will not argue for it > +- **0** : I have no opinion > +- **-1** : I am not happy with this proposal, but will not argue against it > +- **-2** : I am not happy with this proposal, and I will argue against it > + > +A **-2** should include an alternative proposal or a detailed explanation of > +the reasons for the negative opinion. A **+2** should include reasons for the > +positive opinion. > + > +How we tally results and their implications depend on the context in which is > +is used and are marked with Passed/Failed: in one of the following sections: > + > +- [Lazy Consensus / Lazy Voting](#lazyconsensus) > +- [Leadership Team Decisions](#leadership) > +- [Project Wide Decision Making](#project-decisions) > + > +### Lazy Consensus / Lazy Voting {#lazyconsensus} > + > +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 decision (see below). Lazy Consensus is extremely useful, when you don't > +anticipate any objections, or to gauge whether there are objections to a > +proposal. The concrete process in this section is a mixture between Lazy Consensus > +and Lazy Voting and is designed to avoid unnecessary multiple stages in decision > +making. > + > +To make use of it, post something like the following on the project's > +mailing list (or some other communication channel): > + > + > 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. < > + > +You should however ensure that all relevant stake-holders which may object are > +explicitly CC'ed, such as relevant maintainers or committers, ensure that > +**lazy consensus** 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. > + > +Objections by stake-holders should be expressed using the [conventions > +above](#expressingopinion) to make disagreements easily identifiable. > + > +__Passed/Failed:__ > +The proposer of Lazy Consensus decision is assumed to implicitly have an > +opinion of **+1**, unless otherwise stated. > + > +- Failed: A single **-2** by a stake-holder whose approval is necessary > +- Failed: A total sum of opinions **<=0** > +- Passed: A total sum of opinions **>0** > + > +It can only be overturned if the project leadership agrees collectively, that > +the decision is too important to be settled by lazy consensus / lazy voting. > +In situations where a proposal is failed, an alternative solution needs to be > +found, or if a decision is formally challenged, [conflict resolution mechanisms](#conflict) may need to be used to resolve the situation. > + > +__Further Examples:__ > +A Lazy Consensus decision starts out with the implicit **+1** opinion of the > +proposer. If there is no explicit response, the proposal passes as the sum > +is **>0**. > + > +If there is a single **-1** without any **+** votes, the proposal fails. > + > +If there are multiple **+1**'s or **+2**'s, more **-1**'s than positive votes > +are needed for the proposal to fail. This mechanism, is often also called > +**Lazy Voting**. > + > +The process does allow for a proposer to state a starting opinion of **0** or > +**-1**. In this case, the Lazy Consensus label does not work for the process, > +as positive opinions are needed for the proposal to pass. To make use of this > +mechanism, post something like the following on the project's mailing list > +(or some other communication channel) > + > + > I want to solicit opinions on X and am going to assume lazy voting: < > + > My starting position is **0**, as I feel that at least one other < > + > stake-holder should agree with the proposal. < > + > If there is a majority in favour, without a **-2** objection within the < > + > next seven days, I assume that the proposal holds and does not need < > + > require further discussion. < > + > +Unlike in the lazy consensus case, a single **+1** vote is needed. Otherwise > +the proposal fails. Otherwise, the counting rules follow the general case. > + > +This can be useful in situations, where the proposer is not quite sure about > +his/her position, or where the invoker acts on behalf of the community to > +resolve a discussion which has become stuck. A starting position of **-1** can > +be used to verify that a specific approach may be a bad idea: whether this is > +really useful, has to be verified as we start using this process. > + > +### Informal Votes or Surveys > + > +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 > +[conventions above](#expressingopinion) to identify the strongest proposal. > +Once the strongest candidate has been identified, [lazy > +consensus](#lazyconsensus) could be used to close the discussion. In some > +situation, a specific survey may need to be created, to help identify gauging > +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. > + > +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 [conventions > +above](#expressingopinion), 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. > + > +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 anonymously. > + > +### Leadership Team Decisions {#leadership} > + > +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: > + > +- 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. > +- Decisions related to sub-project assets that are not clearly owned (e.g. > +unowned code, project wide assets such as test infrastructure, etc.). > +- Decisions related to nominating and confirming leadership roles within the > +sub-project. This includes [decisions to creating and filling specialised new > +roles](#elections), such as release managers or similar, including their scope > +and set of responsibilities. > +- Resolving [conflicts](#conflict) within the sub-project that cannot > +otherwise be resolved. > + > +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 [decision making conventions](#expressingopinion). 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 **not** 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 leadership > +team, can ask the community manager, to arrange an anonymous vote on behalf > +of the leadership team. > + > +Decisions (also called Resolutions) require a **2/3rd** majority amongst active > +leadership team members in favour of a proposal. The tallying of votes follows > +the rules outlined below. Note that a minimum of 3 leadership team members is > +needed for a [leadership team to function](#exceptional-circumstances). > + > +Leadership team decisions normally have to be made actively: in other words > +each team member has to cast a vote **explicitly** expressing their opinion. > +The only exception are face-2-face or on-line meetings with a quorum of > +**2/3rd** 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. > + > +__Passed/Failed Resolutions:__ > + > +Voting is conducted in line with the following rules: > + > +- Project leadership team members vote for (**+1**) or against (**-1**) a > +resolution. There is no differentiation between **+1**/ **+2** and > +**-1**/**-2**: in other words a **+2** is counted as a vote for, a **-2** as a > +vote against the resolution. The number of votes for and against a resolution > +is called **active vote**. **0** votes **are not counted** as an active vote. > +- A **quorum of at least 1/3 of positive votes for a proposal** is required for a > +resolution to pass. In other words, if the leadership team has 7 members, at > +least 3 members need to vote for the resolution. > +- The resolution passes, if a 2/3 majority of active votes is in favour of > +it. > + > +The table below maps the number of leadership team members against the > +required quorum: > + > + ------------------------------------- --- -- -- -- -- -- -- -- -- > + **Leadership team members** 10 9 8 7 6 5 4 3 2 > + **Positive votes needed for quorum** 4 3 3 3 2 2 2 1 1 > + ------------------------------------- --- -- -- -- -- -- -- -- -- > + > +The table below maps active votes against votes needed to pass: > + > + ------------------------------------- --- -- -- -- -- -- -- -- -- > + **Active Votes (+1 or -1)** 10 9 8 7 6 5 4 3 2 > + **Positive votes needed to pass** 7 6 6 5 4 4 3 2 2 > + ------------------------------------- --- -- -- -- -- -- -- -- -- > + > +### Conflict Resolution {#conflict} > > Sub-projects and teams hosted on Xenproject.org are not democracies but > meritocracies. In situations where there is disagreement on issues related to > -the day-to-day running of the project, Committers and Project Leads are > -expected to act as referees and make a decision on behalf of the community. > -Referees should however consider whether making a decision may be divisive and > -damaging for the community. In such cases, the committer community of the > -project can privately vote on an issue, giving the decision more weight. > - > -#### Last Resort > +the day-to-day running of the project, the [project leadership > +team](#leadership) 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. > > -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. > +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. > > -For questions that affect several projects, committers and project leads of > -mature projects will hold a private majority vote. If the vote is tied, the > -[Xen Project Advisory Board](/join.html) will break the tie through a casting > -vote. > +In situations where the entire Xen Project community becomes paralysed the > +impacted project leadership teams or project leads should work with the > +community manager or advisory board to find a way forward. > > -### Elections > +### Elections {#elections} > > #### Maintainer Elections > > -Developers who have earned the trust of maintainers (including the project > -lead) can be promoted to Maintainer. A two stage mechanism is used > +Developers who have earned the trust of existing maintainers can be promoted to > +maintainer. A two stage mechanism is used > > - Nomination: A maintainer should nominate himself by proposing a patch to > the MAINTAINERS file or mailing a nomination to the project's mailing list. > @@ -211,15 +466,15 @@ as a scope (set of owned components). Where the case is not obvious, evidence > such as specific patches and other evidence supporting the nomination should be > cited. > - Confirmation: Normally, there is no need for a direct election to confirm a > -new maintainer. Discussion should happen on the mailing list using the > -principles of consensus decision making. If there is disagreement or doubt, the > -project lead or a committer should ask the community manager to arrange a more > -formal vote. > +new maintainer. Discussion should happen on the mailing list using the normal > +decision making process. If there is disagreement or doubt, the decision is > +handled by the project leadership. > > -#### Committer Elections > +#### Committer and other Project Leadership Elections > > Developers who have earned the trust of committers in their project can through > -election be promoted to Committer. A two stage mechanism is used > +election be promoted to Committer or Project Leadership (if not covered otherwise). > +A two stage mechanism is used > > - Nomination: Community members should nominate candidates by posting a > proposal to *appointments at xenproject dot org* explaining the candidate's > @@ -230,58 +485,130 @@ review all proposals, check whether the nominee would be willing to accept the > nomination and publish suitable nominations on the project's public mailing > list for wider community input. > - Election: A committer will be elected using the decision making process > -outlined earlier. Voting will be done by committers for that project privately > -using a voting form that is created by the community manager. Should there be a > -negative vote the project lead and community manager will try and resolve the > -situation and reach consensus. Results will be published on the public mailing > -list. > +outlined earlier. In other words, the decision is delegated to the [project > +leadership team](#leadership). > + > +#### Security Response Team Members > + > +Developers who have earned the trust of other security team members can > +be promoted to be on the security team. Due to the specific needs of the > +security team, promotions are typically made by the security team itself > +and confirmed by lazy consensus within the team. > > #### Project Lead Elections > > -Projects which lose their project lead are at risk of failing. Should this > -occur, the project's maintainer community should agree who would want to be/be > -able to be the new project lead and follow the election process as outlined > -above. > - > -Formal Votes {#formal-votes} > ------------- > - > -Sometimes it is necessary to conduct formal voting within the community > -(outside of elections). Formal votes are necessary when processes and > -procedures are introduced or changed, or as part of the [Project > -Governance](#project-governance). Who is eligible to vote, depends on whether > -the scope of a process or procedure is **local** to a sub-project or team, or > -whether it affects **all sub-projects** (or in other words, is **global**). > -Examples of local scope is the [Security Policy](/security-policy.html) which > -applies to the [Hypervisor Project](/developers/teams/hypervisor.html) only. > -Examples of global scope are changes to this document or votes outlined in the > -Project Governance. > - > - ----------------------------------------------------------------------------- > - **Scope** **Who reviews?** **Who votes?** > - ------------ ---------------------- ----------------------------------------- > - **Local** Members of developer Maintainers of the project (or projects), > - mailing lists of the which are affected by the process, > - affected projects. procedure, etc. are allowed to vote. > - This includes maintainers from incubation > - projects (if the scope affects the > - project). > - > - **Global** Members of all Maintainers of **all mature** projects > - developer mailing and the Xenproject.org community manager > - lists of all are allowed to vote. > - sub-projects hosted on > - Xenproject.org. > - ----------------------------------------------------------------------------- > -\ > +Projects which have a project lead, should vote for a project lead in an > +anonymous vote amongst the project leadership. > + > +### Project Wide Decision Making {#project-decisions} > + > +Project wide decisions are made through **formal global votes** and are > +conducted in rare circumstances only, following the principle of [local > +decision making](#principles). Global votes are only needed, when all sub-projects > +hosted on Xenproject.org are affected. This is true, only for: > + > +- Specific votes on creating, graduating, completing/archiving of > +sub-projects as outlined in [project governance](#project-governance). > +- Changes to this document, where sub-projects cannot specialise. In > +particular the sections: [goals](#goals), [principles](#principles), [project > +wide decision making](#project-decisions) and [project > +governance](#project-governance) (and small parts of [Xen Project wide > +roles](#roles-global), [project team roles](#roles-local) and [decision > +making](#decisions) that are needed for project governance or **apply to all > +sub-projects** as stated in those sections). > +- 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 [project team > +roles](#roles-local) and [decision making](#decisions). These sections define > +the **gold standard** 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. > +- Changes to existing global namespace policies (e.g. [Mailing List > +Conventions](/help/mailing-list/100-misc/139-mailing-list-conventions.html)) > +and creation of new project wide namespace policies. > +- 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. > + > +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: > + > + ----------------------------------------------------------------------------------------- > + **Proposal** **Who reviews?** **Who votes?** > + ----------------------------- ----------------------------- ----------------------------- > + Creating, graduating, Members of developer mailing Leadership teams of > + completing/archiving of lists of qualifying projects **mature** sub-projects, > + 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). > + > + Global Process Changes Members of developer mailing Leadership teams of > + lists of qualifying projects **mature** sub-projects, > + within the scope described > + above. > + ----------------------------------------------------------------------------------------- > + > > The community manager first arranges a public review, followed by a timed > private vote. Public review and voting should be open for a minimum of a week > each. For voting a traceable poll mechanism (e.g. voting form that keeps > -auditable and tamper proof records) must be used. Voting follows the > -conventions as laid out in "Principle: Consensus Decision Making". > - > -Project Governance {#project-governance} > +auditable and tamper proof records) must be used. > + > +Voting is conducted **per project** in line with the following rules: > + > +- Each qualifying project's vote is counted per project and then aggregated > +as outlined below. > +- Project leadership team members vote for or against a proposal (there is no > +differentiation between **-1**/**-2** and **+1**/**+2**). A **0** vote is not > +counted as a valid vote. > +- A **quorum of at least least 1/3 of positive votes** of each project's > +leadership team members is required. In other words: if a project's leadership > +team does not achieve the quorum, the entire sub-project's vote is not counted. > +This avoids situations where only a minority of leadership team members vote, > +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 > +community manager. > + > +__Passed/Failed Resolutions:__ > + > +- 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. > +- 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). > +- 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%). > +- If the total vote achieves a 2/3rd majority in favour, the proposal passes. > +Otherwise it fails. > + This is basically the same voting mechanism described under "Leadership Team Decisions", counted per project, then averaged, isn't? It worries me that it could lead to very different results depending on the project leadership team sizes. For example, let's say that only 2 projects reach the quorum: project A, leadership team size 2, total positive votes 2, 100% project B, leadership team size 12, negative votes 8, positive votes 4, 33% Total favor 66.5% -> pass (or very close to) However I don't have a concrete suggestion on how to improve this. Given that any project could appoint any number of people in their leadership teams, I am not sure that accounting for the size of the teams would make things much better. On the other hand the number of people in the leadership team should represent the size of the project somewhat, so it could make sense to account for the votes proportionally. Any opinions? For everything else, you have my +1. For this section, I'll think about it a bit more :-)
On 30/11/2016 23:27, "Stefano Stabellini" <sstabellini@kernel.org> wrote: >On Wed, 23 Nov 2016, Lars Kurth wrote: >> >> -Formal Votes {#formal-votes} >> ------------- >> - >> -Sometimes it is necessary to conduct formal voting within the >>community >> -(outside of elections). Formal votes are necessary when processes and >> -procedures are introduced or changed, or as part of the [Project >> -Governance](#project-governance). Who is eligible to vote, depends on >>whether >> -the scope of a process or procedure is **local** to a sub-project or >>team, or >> -whether it affects **all sub-projects** (or in other words, is >>**global**). >> -Examples of local scope is the [Security >>Policy](/security-policy.html) which >> -applies to the [Hypervisor Project](/developers/teams/hypervisor.html) >>only. >> -Examples of global scope are changes to this document or votes >>outlined in the >> -Project Governance. >> - >> - >>------------------------------------------------------------------------- >>---- >> - **Scope** **Who reviews?** **Who votes?** >> - ------------ ---------------------- >>----------------------------------------- >> - **Local** Members of developer Maintainers of the project (or >>projects), >> - mailing lists of the which are affected by the >>process, >> - affected projects. procedure, etc. are allowed to >>vote. >> - This includes maintainers from >>incubation >> - projects (if the scope affects >>the >> - project). >> - >> - **Global** Members of all Maintainers of **all mature** >>projects >> - developer mailing and the Xenproject.org community >>manager >> - lists of all are allowed to vote. >> - sub-projects hosted on >> - Xenproject.org. >> - >>------------------------------------------------------------------------- >>---- >> -\ >> +Projects which have a project lead, should vote for a project lead in >>an >> +anonymous vote amongst the project leadership. >> + >> +### Project Wide Decision Making {#project-decisions} >> + >> +Project wide decisions are made through **formal global votes** and >>are >> +conducted in rare circumstances only, following the principle of >>[local >> +decision making](#principles). Global votes are only needed, when all >>sub-projects >> +hosted on Xenproject.org are affected. This is true, only for: >> + >> +- Specific votes on creating, graduating, completing/archiving of >> +sub-projects as outlined in [project governance](#project-governance). >> +- Changes to this document, where sub-projects cannot specialise. In >> +particular the sections: [goals](#goals), [principles](#principles), >>[project >> +wide decision making](#project-decisions) and [project >> +governance](#project-governance) (and small parts of [Xen Project wide >> +roles](#roles-global), [project team roles](#roles-local) and >>[decision >> +making](#decisions) that are needed for project governance or **apply >>to all >> +sub-projects** as stated in those sections). >> +- 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 [project >>team >> +roles](#roles-local) and [decision making](#decisions). These sections >>define >> +the **gold standard** 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. >> +- Changes to existing global namespace policies (e.g. [Mailing List >> >>+Conventions](/help/mailing-list/100-misc/139-mailing-list-conventions.ht >>ml)) >> +and creation of new project wide namespace policies. >> +- 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. >> + >> +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: >> + >> + >>------------------------------------------------------------------------- >>---------------- >> + **Proposal** **Who reviews?** **Who >>votes?** >> + ----------------------------- ----------------------------- >>----------------------------- >> + Creating, graduating, Members of developer mailing >>Leadership teams of >> + completing/archiving of lists of qualifying projects >>**mature** sub-projects, >> + 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). >> + >> + Global Process Changes Members of developer mailing >>Leadership teams of >> + lists of qualifying projects >>**mature** sub-projects, >> + within >>the scope described >> + above. >> + >>------------------------------------------------------------------------- >>---------------- >> + >> >> The community manager first arranges a public review, followed by a >>timed >> private vote. Public review and voting should be open for a minimum of >>a week >> each. For voting a traceable poll mechanism (e.g. voting form that >>keeps >> -auditable and tamper proof records) must be used. Voting follows the >> -conventions as laid out in "Principle: Consensus Decision Making". >> - >> -Project Governance {#project-governance} >> +auditable and tamper proof records) must be used. >> + >> +Voting is conducted **per project** in line with the following rules: >> + >> +- Each qualifying project's vote is counted per project and then >>aggregated >> +as outlined below. >> +- Project leadership team members vote for or against a proposal >>(there is no >> +differentiation between **-1**/**-2** and **+1**/**+2**). A **0** vote >>is not >> +counted as a valid vote. >> +- A **quorum of at least least 1/3 of positive votes** of each >>project's >> +leadership team members is required. In other words: if a project's >>leadership >> +team does not achieve the quorum, the entire sub-project's vote is not >>counted. >> +This avoids situations where only a minority of leadership team >>members vote, >> +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 >> +community manager. >> + >> +__Passed/Failed Resolutions:__ >> + >> +- 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. >> +- 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). >> +- 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%). >> +- If the total vote achieves a 2/3rd majority in favour, the >>proposal passes. >> +Otherwise it fails. >> + > >This is basically the same voting mechanism described under "Leadership >Team >Decisions", counted per project, then averaged, isn't? That is correct. >It worries me that it could lead to very different results depending on >the project leadership team sizes. > >For example, let's say that only 2 projects reach the quorum: >project A, leadership team size 2, total positive votes 2, 100% >project B, leadership team size 12, negative votes 8, positive votes 4, >33% >Total favor 66.5% -> pass (or very close to) The issue that prompted this change was in effect created by the number of committers in different mature projects (aka, the fact that XAPI has 12 - 14 - I have to verify the correct number, as some people in the XAPI committer list don't work on XAPI any more). Where according to the current scheme, projects with large leadership teams can in effect use their larger voting block to get their opinion through. One way of maybe addressing this, would be to be more specific about the minimum size of a Leadership team (see "Projects without functional Project Leadership Team"). I think a team needs to have at least 3 members to be functional. Another way to add an extra check may be to add a specific requirement to Graduation Review which checks that the Leadership team is of an appropriate size for the size of the project (although we may have to be specific on what an appropriate size is). In reality, we don't have a problem with this today, as the leadership teams for the two mature projects (XAPI and Hypervisor) are actually large. We have * 7 for the Hypervisor * 12 for XAPI (although this is probably to big, but in reality participation tends to be low) The two projects which could qualify for maturity in the coming year are Win PV drivers (3 leadership team members) and MirageOS (probably should have a similar size to the Hypervisor Team). Also, it is worthwhile pointing out, that Global Decisions should practically hardly ever be needed. Only in the following situations 1) Creating, graduating, completing/archiving of sub-projects 2) Some changes to this document (goals, principles, project wide decision making and project governance): if we apply the new rules, only this change would need a global decision (as we added a principle and changed local decision making). And this would be the first one, we had since introducing the governance 5 years ago 3) Namespace issues: aka naming conventions for lists, ... - which primarily would be bike-shed issues. But again we only used this once 4) Boundary issues: aka making local per-subproject policies and conventions global >However I don't have a concrete suggestion on how to improve this. Given >that any project could appoint any number of people in their leadership >teams, I am not sure that accounting for the size of the teams would >make things much better. On the other hand the number of people in the >leadership team should represent the size of the project somewhat, so it >could make sense to account for the votes proportionally. > >Any opinions? The only other way I can think of is to weight a project's vote by some level of activity (e.g. proportion of contributions averaged over 3 years). But that would become complicated. Another way may be to add an extra bucket which contains all projects. In the example above project A, leadership team size 2, total positive votes 2, 100% (pass) project B, leadership team size 12, negative votes 8, positive votes 4, 33% (fail) ALL (which is like the popular vote): size 14, negative votes 8, positive votes 6, 42% (fail) Average 58% (or very close to) -> fail ... which does change this example Or some sort of rule, which requires that the popular and aggregated votes have to be within a certain percentage of each other, otherwise the vote does not count and has to be repeated >For everything else, you have my +1. >For this section, I'll think about it a bit more :-) Please do Best Regards Lars
On 01/12/2016 09:52, "Lars Kurth" <lars.kurth@citrix.com> wrote: >On 30/11/2016 23:27, "Stefano Stabellini" <sstabellini@kernel.org> wrote: > >>On Wed, 23 Nov 2016, Lars Kurth wrote: >>> >>> >> >>This is basically the same voting mechanism described under "Leadership >>Team >>Decisions", counted per project, then averaged, isn't? > >That is correct. > >>It worries me that it could lead to very different results depending on >>the project leadership team sizes. >> >>For example, let's say that only 2 projects reach the quorum: >>project A, leadership team size 2, total positive votes 2, 100% >>project B, leadership team size 12, negative votes 8, positive votes 4, >>33% >>Total favor 66.5% -> pass (or very close to) > >The issue that prompted this change was in effect created by the number of >committers in different mature projects (aka, the fact that XAPI has 12 - >14 - I have to verify the correct number, as some people in the XAPI >committer list don't work on XAPI any more). Where according to the >current scheme, projects with large leadership teams can in effect use >their larger voting block to get their opinion through. > >One way of maybe addressing this, would be to be more specific about the >minimum size of a Leadership team (see "Projects without functional >Project Leadership Team"). I think a team needs to have at least 3 members >to be functional. Another way to add an extra check may be to add a >specific requirement to Graduation Review which checks that the Leadership >team is of an appropriate size for the size of the project (although we >may have to be specific on what an appropriate size is). > >In reality, we don't have a problem with this today, as the leadership >teams for the two mature projects (XAPI and Hypervisor) are actually >large. We have >* 7 for the Hypervisor >* 12 for XAPI (although this is probably to big, but in reality >participation tends to be low) > >The two projects which could qualify for maturity in the coming year are >Win PV drivers (3 leadership team members) and MirageOS (probably should >have a similar size to the Hypervisor Team). > >Also, it is worthwhile pointing out, that Global Decisions should >practically hardly ever be needed. Only in the following situations >1) Creating, graduating, completing/archiving of sub-projects >2) Some changes to this document (goals, principles, project wide decision >making and project governance): if we apply the new rules, only this >change would need a global decision (as we added a principle and changed >local decision making). And this would be the first one, we had since >introducing the governance 5 years ago >3) Namespace issues: aka naming conventions for lists, ... - which >primarily would be bike-shed issues. But again we only used this once >4) Boundary issues: aka making local per-subproject policies and >conventions global > >>However I don't have a concrete suggestion on how to improve this. Given >>that any project could appoint any number of people in their leadership >>teams, I am not sure that accounting for the size of the teams would >>make things much better. On the other hand the number of people in the >>leadership team should represent the size of the project somewhat, so it >>could make sense to account for the votes proportionally. >> >>Any opinions? > >The only other way I can think of is to weight a project's vote by some >level of activity (e.g. proportion of contributions averaged over 3 >years). But that would become complicated. > >Another way may be to add an extra bucket which contains all projects. In >the example above > >project A, leadership team size 2, total positive votes 2, 100% (pass) >project B, leadership team size 12, negative votes 8, positive votes 4, >33% (fail) >ALL (which is like the popular vote): size 14, negative votes 8, positive >votes 6, 42% (fail) >Average 58% (or very close to) -> fail ... which does change this example > > >Or some sort of rule, which requires that the popular and aggregated votes >have to be within a certain percentage of each other, otherwise the vote >does not count and has to be repeated I thought a bit more about this. Another way to look at it, which may be simpler, is to require that the "popular vote" A) Has a minimum requirement of 1/2 of the votes in favour. B) Or possibly better that there is a simple majority in the popular vote In this example, the total number of leadership team members across both teams is 14: the total number of votes in favour for the proposal is 6 and 8 against. So it would fail on a quorum requirement. Let's just look at this scenario in different ways: aka make it closer A: 2/2 in favour (100%) pass B: 5/12 in favour (41.666%) fail ALL: 7/14 in favour (50%) pass quorum, but no majority, fail 2/3 vote Average (A+B) = 70.83333% pass, pass on quorum Average (A+B+ALL) = 63.888% (fail on 2/3 vote) I didn't look at the maths, but it looks to me that Average (A+B+ALL) would be quite similar to requiring that ALL also has a simple majority. Maybe Ian has some views on what is better from a theoretical viewpoint: Voting mechanisms are a bit of a hobby of his Another potential issue with the model above is that people could be in several leadership teams (not something we have today). So maybe we need to state that they can only vote once and need to chose for which team they vote. This opens up the possibility of tactical voting. So in the scenario above, X has no choice but to vote for A, as A would not meet the quorum requirement Cheers Lars
Lars Kurth writes ("Re: [PATCH v5 3/3] Significant changes to decision making; some new roles and minor changes"):
> Maybe Ian has some views on what is better from a theoretical viewpoint:
> Voting mechanisms are a bit of a hobby of his
The underlying problem here is that the reality is that the Xen
Project's by-far most important subproject is the hypervisor; that it
seems that the governance probably ought to reflect that; but that it
is difficult to do this without special casing it or providing an
objective metric of the hypervisor subproject's size.
I don't think it is possible to square this circle. Our options are:
1. Explicitly recognise the hypervisor subproject as special.
(This could be done by creating a new `superproject' maturity
category, or simply by naming it explicitly.)
2. Do some kind of bodge which tries to reduce the impact of the
potential unknown management practices of other subprojects
(particularly, that they might appoint lots of leaders).
3. Restructure the hypervisor sub-project.
The current proposal is (2) and has the virtue of not incentivising a
subproject to appoint lots of leaders simply to get more votes
overall. But it is still rather weak because it has to treat the
hypervisor subproject as only one amongst many, so hypervisor leaders
are under-powered and fringe leaders over-powered.
Another way to deal with this would be to split the hypervisor
subproject (3, above). For example, we could create subprojects for
some subset of minios, osstest, xtf, various out-of-tree tools,...
(many of which would have only one leadership team member).
That would mean that the hypervisor-focused maintainers would get
additional votes via their other "hats". (They would still get a vote
in the hypervisor subproject, if they have a hypervisor leadership
position too.)
This is perhaps less unnatural. It still leaves fringe leaders
somewhat over-powered: this time, leaders of more-hypervisor-related
(or some such) fringe things, rather than leaders of
less-hypervisor-related fringe things.
> Another potential issue with the model above is that people could be in
> several leadership teams (not something we have today). So maybe we need
> to state that they can only vote once and need to chose for which team
> they vote. This opens up the possibility of tactical voting.
This is a bad idea for the reason you say. If someone gets two votes
in this way, so be it.
Ian.
On Thu, 1 Dec 2016, Ian Jackson wrote: > Lars Kurth writes ("Re: [PATCH v5 3/3] Significant changes to decision making; some new roles and minor changes"): > > Maybe Ian has some views on what is better from a theoretical viewpoint: > > Voting mechanisms are a bit of a hobby of his > > The underlying problem here is that the reality is that the Xen > Project's by-far most important subproject is the hypervisor; that it > seems that the governance probably ought to reflect that; but that it > is difficult to do this without special casing it or providing an > objective metric of the hypervisor subproject's size. > > I don't think it is possible to square this circle. Our options are: > > 1. Explicitly recognise the hypervisor subproject as special. > (This could be done by creating a new `superproject' maturity > category, or simply by naming it explicitly.) > > 2. Do some kind of bodge which tries to reduce the impact of the > potential unknown management practices of other subprojects > (particularly, that they might appoint lots of leaders). > > 3. Restructure the hypervisor sub-project. > > The current proposal is (2) and has the virtue of not incentivising a > subproject to appoint lots of leaders simply to get more votes > overall. But it is still rather weak because it has to treat the > hypervisor subproject as only one amongst many, so hypervisor leaders > are under-powered and fringe leaders over-powered. > > Another way to deal with this would be to split the hypervisor > subproject (3, above). For example, we could create subprojects for > some subset of minios, osstest, xtf, various out-of-tree tools,... > (many of which would have only one leadership team member). > > That would mean that the hypervisor-focused maintainers would get > additional votes via their other "hats". (They would still get a vote > in the hypervisor subproject, if they have a hypervisor leadership > position too.) > > This is perhaps less unnatural. It still leaves fringe leaders > somewhat over-powered: this time, leaders of more-hypervisor-related > (or some such) fringe things, rather than leaders of > less-hypervisor-related fringe things. Istinctively, I don't like the idea of splitting up the hypervisor project in multiple projects. I am no voting expert, but maybe we could consider explicitly weighting each project differently. The advantage is that the mechanism would be obvious rather than implicit. For example "Project A = 10" and "Project B = 6". In the previous example: project A, weight 6, leadership team size 2, total positive votes 2, 100% project B, weight 10, leadership team size 12, negative votes 8, positive votes 4, 33% Total favor: (100*6 + 33*10) / (6+10) = 58.12 -> fail The problem is how to come up with the numbers in the first place and how to update them when necessary, to reflect changes in maturity, size and activity of a project. For the sake of updating the document and moving forward with the other, more important, changes, could we postpone modifications to project wide changes? Or just separate them out to a different patch so that most people can give their +1 to the other patches?
On 01/12/2016 22:36, "Stefano Stabellini" <sstabellini@kernel.org> wrote: >On Thu, 1 Dec 2016, Ian Jackson wrote: >> Lars Kurth writes ("Re: [PATCH v5 3/3] Significant changes to decision >>making; some new roles and minor changes"): >> > Maybe Ian has some views on what is better from a theoretical >>viewpoint: >> > Voting mechanisms are a bit of a hobby of his >> >> The underlying problem here is that the reality is that the Xen >> Project's by-far most important subproject is the hypervisor; that it >> seems that the governance probably ought to reflect that; but that it >> is difficult to do this without special casing it or providing an >> objective metric of the hypervisor subproject's size. >> >> I don't think it is possible to square this circle. Our options are: >> >> 1. Explicitly recognise the hypervisor subproject as special. >> (This could be done by creating a new `superproject' maturity >> category, or simply by naming it explicitly.) >> >> 2. Do some kind of bodge which tries to reduce the impact of the >> potential unknown management practices of other subprojects >> (particularly, that they might appoint lots of leaders). >> >> 3. Restructure the hypervisor sub-project. >> >> The current proposal is (2) and has the virtue of not incentivising a >> subproject to appoint lots of leaders simply to get more votes >> overall. But it is still rather weak because it has to treat the >> hypervisor subproject as only one amongst many, so hypervisor leaders >> are under-powered and fringe leaders over-powered. >> >> Another way to deal with this would be to split the hypervisor >> subproject (3, above). For example, we could create subprojects for >> some subset of minios, osstest, xtf, various out-of-tree tools,... >> (many of which would have only one leadership team member). >> >> That would mean that the hypervisor-focused maintainers would get >> additional votes via their other "hats". (They would still get a vote >> in the hypervisor subproject, if they have a hypervisor leadership >> position too.) >> >> This is perhaps less unnatural. It still leaves fringe leaders >> somewhat over-powered: this time, leaders of more-hypervisor-related >> (or some such) fringe things, rather than leaders of >> less-hypervisor-related fringe things. > >Istinctively, I don't like the idea of splitting up the hypervisor >project in multiple projects. > >I am no voting expert, but maybe we could consider explicitly weighting >each project differently. The advantage is that the mechanism would be >obvious rather than implicit. For example "Project A = 10" and "Project >B = 6". In the previous example: > >project A, weight 6, leadership team size 2, total positive votes 2, 100% >project B, weight 10, leadership team size 12, negative votes 8, positive >votes 4, 33% >Total favor: (100*6 + 33*10) / (6+10) = 58.12 -> fail > >The problem is how to come up with the numbers in the first place and >how to update them when necessary, to reflect changes in maturity, size >and activity of a project. > >For the sake of updating the document and moving forward with the other, >more important, changes, could we postpone modifications to project wide >changes? Or just separate them out to a different patch so that most >people can give their +1 to the other patches? Sure: these are fairly independent. I don't want to re-run the vote: so I propose to a) just apply the bulk of the changes on the website (v3 of governance) b) I will split out the remaining ones around global Voting and re-send as separate patch (v3.1) This is because I don't have enough time before going on winter Vacation. Is this workable? Lars
On Thu, 1 Dec 2016, Lars Kurth wrote: > On 01/12/2016 22:36, "Stefano Stabellini" <sstabellini@kernel.org> wrote: > > >On Thu, 1 Dec 2016, Ian Jackson wrote: > >> Lars Kurth writes ("Re: [PATCH v5 3/3] Significant changes to decision > >>making; some new roles and minor changes"): > >> > Maybe Ian has some views on what is better from a theoretical > >>viewpoint: > >> > Voting mechanisms are a bit of a hobby of his > >> > >> The underlying problem here is that the reality is that the Xen > >> Project's by-far most important subproject is the hypervisor; that it > >> seems that the governance probably ought to reflect that; but that it > >> is difficult to do this without special casing it or providing an > >> objective metric of the hypervisor subproject's size. > >> > >> I don't think it is possible to square this circle. Our options are: > >> > >> 1. Explicitly recognise the hypervisor subproject as special. > >> (This could be done by creating a new `superproject' maturity > >> category, or simply by naming it explicitly.) > >> > >> 2. Do some kind of bodge which tries to reduce the impact of the > >> potential unknown management practices of other subprojects > >> (particularly, that they might appoint lots of leaders). > >> > >> 3. Restructure the hypervisor sub-project. > >> > >> The current proposal is (2) and has the virtue of not incentivising a > >> subproject to appoint lots of leaders simply to get more votes > >> overall. But it is still rather weak because it has to treat the > >> hypervisor subproject as only one amongst many, so hypervisor leaders > >> are under-powered and fringe leaders over-powered. > >> > >> Another way to deal with this would be to split the hypervisor > >> subproject (3, above). For example, we could create subprojects for > >> some subset of minios, osstest, xtf, various out-of-tree tools,... > >> (many of which would have only one leadership team member). > >> > >> That would mean that the hypervisor-focused maintainers would get > >> additional votes via their other "hats". (They would still get a vote > >> in the hypervisor subproject, if they have a hypervisor leadership > >> position too.) > >> > >> This is perhaps less unnatural. It still leaves fringe leaders > >> somewhat over-powered: this time, leaders of more-hypervisor-related > >> (or some such) fringe things, rather than leaders of > >> less-hypervisor-related fringe things. > > > >Istinctively, I don't like the idea of splitting up the hypervisor > >project in multiple projects. > > > >I am no voting expert, but maybe we could consider explicitly weighting > >each project differently. The advantage is that the mechanism would be > >obvious rather than implicit. For example "Project A = 10" and "Project > >B = 6". In the previous example: > > > >project A, weight 6, leadership team size 2, total positive votes 2, 100% > >project B, weight 10, leadership team size 12, negative votes 8, positive > >votes 4, 33% > >Total favor: (100*6 + 33*10) / (6+10) = 58.12 -> fail > > > >The problem is how to come up with the numbers in the first place and > >how to update them when necessary, to reflect changes in maturity, size > >and activity of a project. > > > >For the sake of updating the document and moving forward with the other, > >more important, changes, could we postpone modifications to project wide > >changes? Or just separate them out to a different patch so that most > >people can give their +1 to the other patches? > > Sure: these are fairly independent. I don't want to re-run the vote: > so I propose to > a) just apply the bulk of the changes on the website > (v3 of governance) > b) I will split out the remaining ones around global > Voting and re-send as separate patch (v3.1) > > This is because I don't have enough time before going on winter > Vacation. > > Is this workable? +1 from me
On 01/12/2016 22:36, "Stefano Stabellini" <sstabellini@kernel.org> wrote: >On Thu, 1 Dec 2016, Ian Jackson wrote: >> Lars Kurth writes ("Re: [PATCH v5 3/3] Significant changes to decision >>making; some new roles and minor changes"): >> > Maybe Ian has some views on what is better from a theoretical >>viewpoint: >> > Voting mechanisms are a bit of a hobby of his >> >> The underlying problem here is that the reality is that the Xen >> Project's by-far most important subproject is the hypervisor; that it >> seems that the governance probably ought to reflect that; but that it >> is difficult to do this without special casing it or providing an >> objective metric of the hypervisor subproject's size. >> >> I don't think it is possible to square this circle. Our options are: >> >> 1. Explicitly recognise the hypervisor subproject as special. >> (This could be done by creating a new `superproject' maturity >> category, or simply by naming it explicitly.) >> >> 2. Do some kind of bodge which tries to reduce the impact of the >> potential unknown management practices of other subprojects >> (particularly, that they might appoint lots of leaders). >> >> 3. Restructure the hypervisor sub-project. >> >> The current proposal is (2) and has the virtue of not incentivising a >> subproject to appoint lots of leaders simply to get more votes >> overall. But it is still rather weak because it has to treat the >> hypervisor subproject as only one amongst many, so hypervisor leaders >> are under-powered and fringe leaders over-powered. >> >> Another way to deal with this would be to split the hypervisor >> subproject (3, above). For example, we could create subprojects for >> some subset of minios, osstest, xtf, various out-of-tree tools,... >> (many of which would have only one leadership team member). >> >> That would mean that the hypervisor-focused maintainers would get >> additional votes via their other "hats". (They would still get a vote >> in the hypervisor subproject, if they have a hypervisor leadership >> position too.) >> >> This is perhaps less unnatural. It still leaves fringe leaders >> somewhat over-powered: this time, leaders of more-hypervisor-related >> (or some such) fringe things, rather than leaders of >> less-hypervisor-related fringe things. > >Istinctively, I don't like the idea of splitting up the hypervisor >project in multiple projects. We could split out the following git repos: mini-os, osstest, raisin, livepatch-build-tools, xtf In terms of contributions per release, there is more activity than Windows PV Drivers, which are a separate project. Lars
On Fri, 2 Dec 2016, Lars Kurth wrote: > On 01/12/2016 22:36, "Stefano Stabellini" <sstabellini@kernel.org> wrote: > > >On Thu, 1 Dec 2016, Ian Jackson wrote: > >> Lars Kurth writes ("Re: [PATCH v5 3/3] Significant changes to decision > >>making; some new roles and minor changes"): > >> > Maybe Ian has some views on what is better from a theoretical > >>viewpoint: > >> > Voting mechanisms are a bit of a hobby of his > >> > >> The underlying problem here is that the reality is that the Xen > >> Project's by-far most important subproject is the hypervisor; that it > >> seems that the governance probably ought to reflect that; but that it > >> is difficult to do this without special casing it or providing an > >> objective metric of the hypervisor subproject's size. > >> > >> I don't think it is possible to square this circle. Our options are: > >> > >> 1. Explicitly recognise the hypervisor subproject as special. > >> (This could be done by creating a new `superproject' maturity > >> category, or simply by naming it explicitly.) > >> > >> 2. Do some kind of bodge which tries to reduce the impact of the > >> potential unknown management practices of other subprojects > >> (particularly, that they might appoint lots of leaders). > >> > >> 3. Restructure the hypervisor sub-project. > >> > >> The current proposal is (2) and has the virtue of not incentivising a > >> subproject to appoint lots of leaders simply to get more votes > >> overall. But it is still rather weak because it has to treat the > >> hypervisor subproject as only one amongst many, so hypervisor leaders > >> are under-powered and fringe leaders over-powered. > >> > >> Another way to deal with this would be to split the hypervisor > >> subproject (3, above). For example, we could create subprojects for > >> some subset of minios, osstest, xtf, various out-of-tree tools,... > >> (many of which would have only one leadership team member). > >> > >> That would mean that the hypervisor-focused maintainers would get > >> additional votes via their other "hats". (They would still get a vote > >> in the hypervisor subproject, if they have a hypervisor leadership > >> position too.) > >> > >> This is perhaps less unnatural. It still leaves fringe leaders > >> somewhat over-powered: this time, leaders of more-hypervisor-related > >> (or some such) fringe things, rather than leaders of > >> less-hypervisor-related fringe things. > > > >Istinctively, I don't like the idea of splitting up the hypervisor > >project in multiple projects. > > We could split out the following git repos: mini-os, osstest, raisin, > livepatch-build-tools, xtf > In terms of contributions per release, there is more activity than Windows > PV Drivers, which are a separate project. I see what you meant now. That could be OK.
Hello everybody! I am Hussain, act as student. I would like to ask few questions about Mirage Unikernel. In fact I built Unikernel on Mirage because I have a project about ti. 1- How can I test booting speed of Unikernel. 2- After how many pings Unikernel is crash down. My Regards On Fri, Dec 2, 2016 at 10:06 PM, Stefano Stabellini <sstabellini@kernel.org> wrote: > On Fri, 2 Dec 2016, Lars Kurth wrote: > > On 01/12/2016 22:36, "Stefano Stabellini" <sstabellini@kernel.org> > wrote: > > > > >On Thu, 1 Dec 2016, Ian Jackson wrote: > > >> Lars Kurth writes ("Re: [PATCH v5 3/3] Significant changes to decision > > >>making; some new roles and minor changes"): > > >> > Maybe Ian has some views on what is better from a theoretical > > >>viewpoint: > > >> > Voting mechanisms are a bit of a hobby of his > > >> > > >> The underlying problem here is that the reality is that the Xen > > >> Project's by-far most important subproject is the hypervisor; that it > > >> seems that the governance probably ought to reflect that; but that it > > >> is difficult to do this without special casing it or providing an > > >> objective metric of the hypervisor subproject's size. > > >> > > >> I don't think it is possible to square this circle. Our options are: > > >> > > >> 1. Explicitly recognise the hypervisor subproject as special. > > >> (This could be done by creating a new `superproject' maturity > > >> category, or simply by naming it explicitly.) > > >> > > >> 2. Do some kind of bodge which tries to reduce the impact of the > > >> potential unknown management practices of other subprojects > > >> (particularly, that they might appoint lots of leaders). > > >> > > >> 3. Restructure the hypervisor sub-project. > > >> > > >> The current proposal is (2) and has the virtue of not incentivising a > > >> subproject to appoint lots of leaders simply to get more votes > > >> overall. But it is still rather weak because it has to treat the > > >> hypervisor subproject as only one amongst many, so hypervisor leaders > > >> are under-powered and fringe leaders over-powered. > > >> > > >> Another way to deal with this would be to split the hypervisor > > >> subproject (3, above). For example, we could create subprojects for > > >> some subset of minios, osstest, xtf, various out-of-tree tools,... > > >> (many of which would have only one leadership team member). > > >> > > >> That would mean that the hypervisor-focused maintainers would get > > >> additional votes via their other "hats". (They would still get a vote > > >> in the hypervisor subproject, if they have a hypervisor leadership > > >> position too.) > > >> > > >> This is perhaps less unnatural. It still leaves fringe leaders > > >> somewhat over-powered: this time, leaders of more-hypervisor-related > > >> (or some such) fringe things, rather than leaders of > > >> less-hypervisor-related fringe things. > > > > > >Istinctively, I don't like the idea of splitting up the hypervisor > > >project in multiple projects. > > > > We could split out the following git repos: mini-os, osstest, raisin, > > livepatch-build-tools, xtf > > In terms of contributions per release, there is more activity than > Windows > > PV Drivers, which are a separate project. > > I see what you meant now. That could be OK. > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > https://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel >
Hi all, I am kind of stuck on this one and wanted to pick up the discussion again. Apologies that it took so long. To to summarise, we all are agreed on most sections of the proposal, with the exception of decision making across projects. One option is to just apply what we agreed on and leave the area which is not agreed as is. However, that is still quite a bit of work, and won't solve the underlying problem. Ian's comments below summarise the situation quite clearly. > On 2 Dec 2016, at 19:06, Stefano Stabellini <sstabellini@kernel.org> wrote: > > On Fri, 2 Dec 2016, Lars Kurth wrote: >> On 01/12/2016 22:36, "Stefano Stabellini" <sstabellini@kernel.org> wrote: >> >>> On Thu, 1 Dec 2016, Ian Jackson wrote: >>>> Lars Kurth writes ("Re: [PATCH v5 3/3] Significant changes to decision >>>> making; some new roles and minor changes"): >>>>> Maybe Ian has some views on what is better from a theoretical >>>> viewpoint: >>>>> Voting mechanisms are a bit of a hobby of his >>>> >>>> The underlying problem here is that the reality is that the Xen >>>> Project's by-far most important subproject is the hypervisor; that it >>>> seems that the governance probably ought to reflect that; but that it >>>> is difficult to do this without special casing it or providing an >>>> objective metric of the hypervisor subproject's size. >>>> >>>> I don't think it is possible to square this circle. Our options are: >>>> >>>> 1. Explicitly recognise the hypervisor subproject as special. >>>> (This could be done by creating a new `superproject' maturity >>>> category, or simply by naming it explicitly.) I think that option is somewhat problematic. >>>> 2. Do some kind of bodge which tries to reduce the impact of the >>>> potential unknown management practices of other subprojects >>>> (particularly, that they might appoint lots of leaders). >>>> >>>> 3. Restructure the hypervisor sub-project. >>>> >>>> The current proposal is (2) and has the virtue of not incentivising a >>>> subproject to appoint lots of leaders simply to get more votes >>>> overall. But it is still rather weak because it has to treat the >>>> hypervisor subproject as only one amongst many, so hypervisor leaders >>>> are under-powered and fringe leaders over-powered. Agreed. As an additional note, I would like to highlight that it also has the advantage of being consistent with the already agreed per-sub-project leadership model. And that the proposed model - although not perfect - is better than what we had before. >>>> Another way to deal with this would be to split the hypervisor >>>> subproject (3, above). For example, we could create subprojects for >>>> some subset of minios, osstest, xtf, various out-of-tree tools,... >>>> (many of which would have only one leadership team member). I am assuming that would mean: - leave the proposal as it is - in addition create a new sub-project, say "Hypervisor Infrastructure" or "Hypervisor Support Infrastructure" (we can debate the name later) That would re-balance the original proposal and give hypervisor maintainers / committers more weight (which mostly also are in the hypervisor project leadership team) and thus address Stefano's concerns. >>>> That would mean that the hypervisor-focused maintainers would get >>>> additional votes via their other "hats". (They would still get a vote >>>> in the hypervisor subproject, if they have a hypervisor leadership >>>> position too.) >>>> >>>> This is perhaps less unnatural. It still leaves fringe leaders >>>> somewhat over-powered: this time, leaders of more-hypervisor-related >>>> (or some such) fringe things, rather than leaders of >>>> less-hypervisor-related fringe things. If we look at the current repos, which could fit into there, aka mini-os, osstest, raisin, livepatch-build-tools & xtf we would end up with the following leadership team. Ian Jackson (osstest) Andrew Cooper (xtf) George Dunlap, Stefano Stabellini (raisin) Ross Lagerwell, Konrad Wilk (livepatch-build-tools) Wei Lui (mini-os) So it makes this very similar to the hypervisor project leadership team, with the exception of Jan. There might be areas such as xtf, which Jan could be potentially interested in. And if ARM support comes along for xtf, that would also give us a route in this direction. We could also include others such as Doug Goldstein, who have been stepping up on some build and quality related initiatives. We would have to formalise who is part of the leadership team, and who does what. But that would be a good idea anyway in my view. >>> Istinctively, I don't like the idea of splitting up the hypervisor >>> project in multiple projects. >> >> We could split out the following git repos: mini-os, osstest, raisin, >> livepatch-build-tools, xtf >> In terms of contributions per release, there is more activity than Windows >> PV Drivers, which are a separate project. > > I see what you meant now. That could be OK. I think that is the cleanest and simplest approach in my view and would unblock this proposal. With this in mind, do you think, this would work? Best Regards Lars
> >> We could split out the following git repos: mini-os, osstest, raisin, > >> livepatch-build-tools, xtf , xentesttools/* > >> In terms of contributions per release, there is more activity than Windows > >> PV Drivers, which are a separate project. > > > > I see what you meant now. That could be OK. > > I think that is the cleanest and simplest approach in my view and would > unblock this proposal. /me nods. > > With this in mind, do you think, this would work? Yes. > > Best Regards > Lars > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > https://lists.xen.org/xen-devel
On Wed, 15 Feb 2017, Lars Kurth wrote: > Hi all, > > I am kind of stuck on this one and wanted to pick up the discussion again. > Apologies that it took so long. > > To to summarise, we all are agreed on most sections of the proposal, > with the exception of decision making across projects. One option is to > just apply what we agreed on and leave the area which is not agreed as is. > However, that is still quite a bit of work, and won't solve the underlying > problem. > > Ian's comments below summarise the situation quite clearly. > > > On 2 Dec 2016, at 19:06, Stefano Stabellini <sstabellini@kernel.org> wrote: > > > > On Fri, 2 Dec 2016, Lars Kurth wrote: > >> On 01/12/2016 22:36, "Stefano Stabellini" <sstabellini@kernel.org> wrote: > >> > >>> On Thu, 1 Dec 2016, Ian Jackson wrote: > >>>> Lars Kurth writes ("Re: [PATCH v5 3/3] Significant changes to decision > >>>> making; some new roles and minor changes"): > >>>>> Maybe Ian has some views on what is better from a theoretical > >>>> viewpoint: > >>>>> Voting mechanisms are a bit of a hobby of his > >>>> > >>>> The underlying problem here is that the reality is that the Xen > >>>> Project's by-far most important subproject is the hypervisor; that it > >>>> seems that the governance probably ought to reflect that; but that it > >>>> is difficult to do this without special casing it or providing an > >>>> objective metric of the hypervisor subproject's size. > >>>> > >>>> I don't think it is possible to square this circle. Our options are: > >>>> > >>>> 1. Explicitly recognise the hypervisor subproject as special. > >>>> (This could be done by creating a new `superproject' maturity > >>>> category, or simply by naming it explicitly.) > > I think that option is somewhat problematic. > > >>>> 2. Do some kind of bodge which tries to reduce the impact of the > >>>> potential unknown management practices of other subprojects > >>>> (particularly, that they might appoint lots of leaders). > >>>> > >>>> 3. Restructure the hypervisor sub-project. > >>>> > >>>> The current proposal is (2) and has the virtue of not incentivising a > >>>> subproject to appoint lots of leaders simply to get more votes > >>>> overall. But it is still rather weak because it has to treat the > >>>> hypervisor subproject as only one amongst many, so hypervisor leaders > >>>> are under-powered and fringe leaders over-powered. > > Agreed. > > As an additional note, I would like to highlight that it also has the > advantage of being consistent with the already agreed per-sub-project > leadership model. > > And that the proposed model - although not perfect - is better than what > we had before. > > >>>> Another way to deal with this would be to split the hypervisor > >>>> subproject (3, above). For example, we could create subprojects for > >>>> some subset of minios, osstest, xtf, various out-of-tree tools,... > >>>> (many of which would have only one leadership team member). > > I am assuming that would mean: > - leave the proposal as it is > - in addition create a new sub-project, say "Hypervisor Infrastructure" > or "Hypervisor Support Infrastructure" (we can debate the name later) > > That would re-balance the original proposal and give hypervisor > maintainers / committers more weight (which mostly also are in the > hypervisor project leadership team) and thus address Stefano's concerns. > > >>>> That would mean that the hypervisor-focused maintainers would get > >>>> additional votes via their other "hats". (They would still get a vote > >>>> in the hypervisor subproject, if they have a hypervisor leadership > >>>> position too.) > >>>> > >>>> This is perhaps less unnatural. It still leaves fringe leaders > >>>> somewhat over-powered: this time, leaders of more-hypervisor-related > >>>> (or some such) fringe things, rather than leaders of > >>>> less-hypervisor-related fringe things. > > If we look at the current repos, which could fit into there, aka > mini-os, osstest, raisin, livepatch-build-tools & xtf we would end up with the > following leadership team. > > Ian Jackson (osstest) > Andrew Cooper (xtf) > George Dunlap, Stefano Stabellini (raisin) > Ross Lagerwell, Konrad Wilk (livepatch-build-tools) > Wei Lui (mini-os) > > So it makes this very similar to the hypervisor project leadership team, > with the exception of Jan. There might be areas such as xtf, which Jan > could be potentially interested in. And if ARM support comes along for xtf, > that would also give us a route in this direction. We could also include > others such as Doug Goldstein, who have been stepping up on some build > and quality related initiatives. > > We would have to formalise who is part of the leadership team, and who > does what. But that would be a good idea anyway in my view. > > >>> Istinctively, I don't like the idea of splitting up the hypervisor > >>> project in multiple projects. > >> > >> We could split out the following git repos: mini-os, osstest, raisin, > >> livepatch-build-tools, xtf > >> In terms of contributions per release, there is more activity than Windows > >> PV Drivers, which are a separate project. > > > > I see what you meant now. That could be OK. > > I think that is the cleanest and simplest approach in my view and would > unblock this proposal. > > With this in mind, do you think, this would work? Yes, I think it would work
> On 15 Feb 2017, at 21:09, Stefano Stabellini <sstabellini@kernel.org> wrote: > >> ... >> >>>>> Istinctively, I don't like the idea of splitting up the hypervisor >>>>> project in multiple projects. >>>> >>>> We could split out the following git repos: mini-os, osstest, raisin, >>>> livepatch-build-tools, xtf >>>> In terms of contributions per release, there is more activity than Windows >>>> PV Drivers, which are a separate project. >>> >>> I see what you meant now. That could be OK. >> >> I think that is the cleanest and simplest approach in my view and would >> unblock this proposal. >> >> With this in mind, do you think, this would work? > > Yes, I think it would work Are there any other views? Given that everyone else seems to have voted or voiced on the proposal already (I need to double check). Assuming that Stefano, was the only person who objected and that otherwise there was consensus, I would suggest the following. Wait for another week for additional views Then summarise who voted in which way, and depending on it either call a formal vote (if there is any doubt) or declare the proposal as accepted. Best Regards Lars
diff --git a/governance.pandoc b/governance.pandoc index 2ce780c..188fa41 100644 --- a/governance.pandoc +++ b/governance.pandoc @@ -1,5 +1,5 @@ This document has come in effect in June 2011 and will be reviewed periodically -(see revision sections). The last modification has been made in July 2016. +(see revision sections). The last modification has been made in December 2016. Content ------- @@ -11,8 +11,10 @@ Content - [Making Contributions](#contributions) - [Decision Making, Conflict Resolution, Role Nominations and Elections](#decisions) -- [Formal Votes](#formal-votes) +- [Project Wide Decision Making](#project-decisions) +- [Community Decisions with Funding and Legal Implications](#funding-and-legal) - [Project Governance](#project-governance) +- [Per Sub-Project Governance Specialisations](#specialisations) Goals {#goals} ----- @@ -54,7 +56,12 @@ 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. -Xen Project Wide Roles {#roles-global} +### Local Decision Making + +The Xen Project consists of a number of sub-projects: each sub-project makes +technical and other decisions that solely affect it locally. + +Xen Project Wide Roles {#roles-global} ---------------------- ### Sub-projects and Teams @@ -64,9 +71,22 @@ the [Project Governance](#project-governance) (or Project Lifecycle) as outlined in this document. Sub-projects (sometimes simply referred to as projects) are run by individuals and are often referred to as teams to highlight the collaborative nature of development. For example, each -sub-project has a [team portal](/developers/teams.html) on Xenproject.org. +sub-project has a [team portal](/developers/teams.html) 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 **sub-project assets** (or team assets) in this document. + +Sub-projects can either be **incubation projects** or **mature projects** as +outlined in [Basic Project Life Cycle](#project-governance). In line with the +meritocratic principle, mature projects have more influence than incubation +projects, on [project wide decisions](#project-decisions). + +### Community Manager -### Xen Project Advisory Board +The Xen Project has a community manager, whose primary role it is to support +the entire Xen Project Community. + +### Xen Project Advisory Board {#roles-ab} The [Xen Project Advisory Board](/join.html) consists of members who are committed to steering the project to advance its market and technical success, @@ -76,7 +96,7 @@ shared project infrastructure, marketing and events, and managing the Xen Project trademark. The Advisory Board leaves all technical decisions to the open source meritocracy. -### The Linux Foundation +### The Linux Foundation {#roles-lf} The Xen Project is a [Linux Foundation](/linux-foundation.html) Collaborative Project. Collaborative Projects are independently funded software projects that @@ -95,21 +115,48 @@ members or other distinguished community members. ### Sponsor To form a new sub-project or team on Xenproject.org, we require a sponsor to -support the creation of the new project. A sponsor can be a project lead or -committer of a mature project, a member of the advisory board or the community -manager. This ensures that a distinguished community member supports the idea -behind the project. +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. Project Team Roles {#roles-local} ------------------ +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 +[document](#specialisations). 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. + +The following table lists how each project uses these roles. Note that +**incubation projects** have more flexibility in experimenting with roles that +work for them, but need to define specializations before they can **mature**. + + --------------------- ------------ ----------------- ---------------- ------------------- -------------------------------------------------------- + **Project** **Mature** **Maintainers** **Committers** **Security Team** **Leadership Team** + **Hypervisor** YES YES YES YES Committers and Release Manager, without a Project Lead + **Windows Drivers** NO YES YES NO Committers, with a Project Lead + **XAPI** YES YES YES NO Committers, with a Project Lead + --------------------- ------------ ----------------- ---------------- ------------------- -------------------------------------------------------- + ### Maintainers -Maintainers own one or several components in the Xen tree. A maintainer reviews -and approves changes that affect their components. It is a maintainer's prime -responsibility to review, comment on, co-ordinate and accept patches from other -community member's and to maintain the design cohesion of their components. -Maintainers are listed in a MAINTAINERS file in the root of the source tree. +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. + +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. ### Committers @@ -119,17 +166,34 @@ applies changes that have been approved by the respective maintainer(s) to the source tree. Due to their status in the community, committers can also act as referees should disagreements amongst maintainers arise. Committers are listed on the sub-project's team portal (e.g. [Hypervisor team -portal](/developers/teams/hypervisor.html)). +portal](/developers/teams/hypervisor.html)) and/or in the projects MAINTAINERS +files. -### Project Lead +### Security Response Team (short: Security Team) -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. +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. +[Hypervisor Security Problem Response Process](/security-policy.html)). + +### Project Leadership Team and Project Lead + +Sub-projects and teams hosted on Xenproject.org are managed by a Project +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 [sub-project wide decisions](#decisions) on behalf of its +community. + +A sub-projects leadership team members are listed on the sub-project's team +portal (e.g. [Hypervisor team portal](developers/teams/hypervisor.html)). + +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 +[referees](#conflict) should the Project Leadership Team become paralysed. Making Contributions {#contributions} -------------------- @@ -146,62 +210,253 @@ More information on making contributions can be found in the following documents: - [Contribution Guidelines](/help/contribution-guidelines.html) +- [Review Then Commit Policy](#RTC) -Decision Making, Conflict Resolution, Role Nominations and Elections -{#decisions} +Decision Making, Conflict Resolution, Role Nominations and Elections {#decisions} -------------------------------------------------------------------- -### Consensus Decision Making - Sub-projects or teams hosted on Xenproject.org are normally auto-governing and driven by the people who volunteer for the job. This functions well for most -cases. When more formal decision making and coordination is required, decisions -are taken with a lazy consensus approach: a few positive votes with no negative -vote are enough to get going. - -Voting is done with numbers: - -- +1 : a positive vote -- 0 : abstain, have no opinion -- -1 : a negative vote - -A negative vote should include an alternative proposal or a detailed -explanation of the reasons for the negative vote. The project community then -tries to gather consensus on an alternative proposal that resolves the issue. -In the great majority of cases, the concerns leading to the negative vote can -be addressed. - -### Conflict Resolution - -#### Refereeing +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 +[document](#specialisation). The only exception is that each project is +required to adhere to the **Review Then Commit Policy**, **Leadership Team +Decisions** and **Conflict Resolution**. + +### Review Then Commit {#RTC} + +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. + +### Expressing Agreement and Disagreement {#expressingopinion} + +Within the community, we follow the following number notation to explicitly +express opinions on proposals, formal or informal votes. + +- **+2** : I am happy with this proposal, and I will argue for it +- **+1** : I am happy with this proposal, but will not argue for it +- **0** : I have no opinion +- **-1** : I am not happy with this proposal, but will not argue against it +- **-2** : I am not happy with this proposal, and I will argue against it + +A **-2** should include an alternative proposal or a detailed explanation of +the reasons for the negative opinion. A **+2** should include reasons for the +positive opinion. + +How we tally results and their implications depend on the context in which is +is used and are marked with Passed/Failed: in one of the following sections: + +- [Lazy Consensus / Lazy Voting](#lazyconsensus) +- [Leadership Team Decisions](#leadership) +- [Project Wide Decision Making](#project-decisions) + +### Lazy Consensus / Lazy Voting {#lazyconsensus} + +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 decision (see below). Lazy Consensus is extremely useful, when you don't +anticipate any objections, or to gauge whether there are objections to a +proposal. The concrete process in this section is a mixture between Lazy Consensus +and Lazy Voting and is designed to avoid unnecessary multiple stages in decision +making. + +To make use of it, post something like the following on the project's +mailing list (or some other communication channel): + + > 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. < + +You should however ensure that all relevant stake-holders which may object are +explicitly CC'ed, such as relevant maintainers or committers, ensure that +**lazy consensus** 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. + +Objections by stake-holders should be expressed using the [conventions +above](#expressingopinion) to make disagreements easily identifiable. + +__Passed/Failed:__ +The proposer of Lazy Consensus decision is assumed to implicitly have an +opinion of **+1**, unless otherwise stated. + +- Failed: A single **-2** by a stake-holder whose approval is necessary +- Failed: A total sum of opinions **<=0** +- Passed: A total sum of opinions **>0** + +It can only be overturned if the project leadership agrees collectively, that +the decision is too important to be settled by lazy consensus / lazy voting. +In situations where a proposal is failed, an alternative solution needs to be +found, or if a decision is formally challenged, [conflict resolution mechanisms](#conflict) may need to be used to resolve the situation. + +__Further Examples:__ +A Lazy Consensus decision starts out with the implicit **+1** opinion of the +proposer. If there is no explicit response, the proposal passes as the sum +is **>0**. + +If there is a single **-1** without any **+** votes, the proposal fails. + +If there are multiple **+1**'s or **+2**'s, more **-1**'s than positive votes +are needed for the proposal to fail. This mechanism, is often also called +**Lazy Voting**. + +The process does allow for a proposer to state a starting opinion of **0** or +**-1**. In this case, the Lazy Consensus label does not work for the process, +as positive opinions are needed for the proposal to pass. To make use of this +mechanism, post something like the following on the project's mailing list +(or some other communication channel) + + > I want to solicit opinions on X and am going to assume lazy voting: < + > My starting position is **0**, as I feel that at least one other < + > stake-holder should agree with the proposal. < + > If there is a majority in favour, without a **-2** objection within the < + > next seven days, I assume that the proposal holds and does not need < + > require further discussion. < + +Unlike in the lazy consensus case, a single **+1** vote is needed. Otherwise +the proposal fails. Otherwise, the counting rules follow the general case. + +This can be useful in situations, where the proposer is not quite sure about +his/her position, or where the invoker acts on behalf of the community to +resolve a discussion which has become stuck. A starting position of **-1** can +be used to verify that a specific approach may be a bad idea: whether this is +really useful, has to be verified as we start using this process. + +### Informal Votes or Surveys + +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 +[conventions above](#expressingopinion) to identify the strongest proposal. +Once the strongest candidate has been identified, [lazy +consensus](#lazyconsensus) could be used to close the discussion. In some +situation, a specific survey may need to be created, to help identify gauging +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. + +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 [conventions +above](#expressingopinion), 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. + +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 anonymously. + +### Leadership Team Decisions {#leadership} + +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: + +- 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. +- Decisions related to sub-project assets that are not clearly owned (e.g. +unowned code, project wide assets such as test infrastructure, etc.). +- Decisions related to nominating and confirming leadership roles within the +sub-project. This includes [decisions to creating and filling specialised new +roles](#elections), such as release managers or similar, including their scope +and set of responsibilities. +- Resolving [conflicts](#conflict) within the sub-project that cannot +otherwise be resolved. + +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 [decision making conventions](#expressingopinion). 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 **not** 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 leadership +team, can ask the community manager, to arrange an anonymous vote on behalf +of the leadership team. + +Decisions (also called Resolutions) require a **2/3rd** majority amongst active +leadership team members in favour of a proposal. The tallying of votes follows +the rules outlined below. Note that a minimum of 3 leadership team members is +needed for a [leadership team to function](#exceptional-circumstances). + +Leadership team decisions normally have to be made actively: in other words +each team member has to cast a vote **explicitly** expressing their opinion. +The only exception are face-2-face or on-line meetings with a quorum of +**2/3rd** 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. + +__Passed/Failed Resolutions:__ + +Voting is conducted in line with the following rules: + +- Project leadership team members vote for (**+1**) or against (**-1**) a +resolution. There is no differentiation between **+1**/ **+2** and +**-1**/**-2**: in other words a **+2** is counted as a vote for, a **-2** as a +vote against the resolution. The number of votes for and against a resolution +is called **active vote**. **0** votes **are not counted** as an active vote. +- A **quorum of at least 1/3 of positive votes for a proposal** is required for a +resolution to pass. In other words, if the leadership team has 7 members, at +least 3 members need to vote for the resolution. +- The resolution passes, if a 2/3 majority of active votes is in favour of +it. + +The table below maps the number of leadership team members against the +required quorum: + + ------------------------------------- --- -- -- -- -- -- -- -- -- + **Leadership team members** 10 9 8 7 6 5 4 3 2 + **Positive votes needed for quorum** 4 3 3 3 2 2 2 1 1 + ------------------------------------- --- -- -- -- -- -- -- -- -- + +The table below maps active votes against votes needed to pass: + + ------------------------------------- --- -- -- -- -- -- -- -- -- + **Active Votes (+1 or -1)** 10 9 8 7 6 5 4 3 2 + **Positive votes needed to pass** 7 6 6 5 4 4 3 2 2 + ------------------------------------- --- -- -- -- -- -- -- -- -- + +### Conflict Resolution {#conflict} Sub-projects and teams hosted on Xenproject.org are not democracies but meritocracies. In situations where there is disagreement on issues related to -the day-to-day running of the project, Committers and Project Leads are -expected to act as referees and make a decision on behalf of the community. -Referees should however consider whether making a decision may be divisive and -damaging for the community. In such cases, the committer community of the -project can privately vote on an issue, giving the decision more weight. - -#### Last Resort +the day-to-day running of the project, the [project leadership +team](#leadership) 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. -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. +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. -For questions that affect several projects, committers and project leads of -mature projects will hold a private majority vote. If the vote is tied, the -[Xen Project Advisory Board](/join.html) will break the tie through a casting -vote. +In situations where the entire Xen Project community becomes paralysed the +impacted project leadership teams or project leads should work with the +community manager or advisory board to find a way forward. -### Elections +### Elections {#elections} #### Maintainer Elections -Developers who have earned the trust of maintainers (including the project -lead) can be promoted to Maintainer. A two stage mechanism is used +Developers who have earned the trust of existing maintainers can be promoted to +maintainer. A two stage mechanism is used - Nomination: A maintainer should nominate himself by proposing a patch to the MAINTAINERS file or mailing a nomination to the project's mailing list. @@ -211,15 +466,15 @@ as a scope (set of owned components). Where the case is not obvious, evidence such as specific patches and other evidence supporting the nomination should be cited. - Confirmation: Normally, there is no need for a direct election to confirm a -new maintainer. Discussion should happen on the mailing list using the -principles of consensus decision making. If there is disagreement or doubt, the -project lead or a committer should ask the community manager to arrange a more -formal vote. +new maintainer. Discussion should happen on the mailing list using the normal +decision making process. If there is disagreement or doubt, the decision is +handled by the project leadership. -#### Committer Elections +#### Committer and other Project Leadership Elections Developers who have earned the trust of committers in their project can through -election be promoted to Committer. A two stage mechanism is used +election be promoted to Committer or Project Leadership (if not covered otherwise). +A two stage mechanism is used - Nomination: Community members should nominate candidates by posting a proposal to *appointments at xenproject dot org* explaining the candidate's @@ -230,58 +485,130 @@ review all proposals, check whether the nominee would be willing to accept the nomination and publish suitable nominations on the project's public mailing list for wider community input. - Election: A committer will be elected using the decision making process -outlined earlier. Voting will be done by committers for that project privately -using a voting form that is created by the community manager. Should there be a -negative vote the project lead and community manager will try and resolve the -situation and reach consensus. Results will be published on the public mailing -list. +outlined earlier. In other words, the decision is delegated to the [project +leadership team](#leadership). + +#### Security Response Team Members + +Developers who have earned the trust of other security team members can +be promoted to be on the security team. Due to the specific needs of the +security team, promotions are typically made by the security team itself +and confirmed by lazy consensus within the team. #### Project Lead Elections -Projects which lose their project lead are at risk of failing. Should this -occur, the project's maintainer community should agree who would want to be/be -able to be the new project lead and follow the election process as outlined -above. - -Formal Votes {#formal-votes} ------------- - -Sometimes it is necessary to conduct formal voting within the community -(outside of elections). Formal votes are necessary when processes and -procedures are introduced or changed, or as part of the [Project -Governance](#project-governance). Who is eligible to vote, depends on whether -the scope of a process or procedure is **local** to a sub-project or team, or -whether it affects **all sub-projects** (or in other words, is **global**). -Examples of local scope is the [Security Policy](/security-policy.html) which -applies to the [Hypervisor Project](/developers/teams/hypervisor.html) only. -Examples of global scope are changes to this document or votes outlined in the -Project Governance. - - ----------------------------------------------------------------------------- - **Scope** **Who reviews?** **Who votes?** - ------------ ---------------------- ----------------------------------------- - **Local** Members of developer Maintainers of the project (or projects), - mailing lists of the which are affected by the process, - affected projects. procedure, etc. are allowed to vote. - This includes maintainers from incubation - projects (if the scope affects the - project). - - **Global** Members of all Maintainers of **all mature** projects - developer mailing and the Xenproject.org community manager - lists of all are allowed to vote. - sub-projects hosted on - Xenproject.org. - ----------------------------------------------------------------------------- -\ +Projects which have a project lead, should vote for a project lead in an +anonymous vote amongst the project leadership. + +### Project Wide Decision Making {#project-decisions} + +Project wide decisions are made through **formal global votes** and are +conducted in rare circumstances only, following the principle of [local +decision making](#principles). Global votes are only needed, when all sub-projects +hosted on Xenproject.org are affected. This is true, only for: + +- Specific votes on creating, graduating, completing/archiving of +sub-projects as outlined in [project governance](#project-governance). +- Changes to this document, where sub-projects cannot specialise. In +particular the sections: [goals](#goals), [principles](#principles), [project +wide decision making](#project-decisions) and [project +governance](#project-governance) (and small parts of [Xen Project wide +roles](#roles-global), [project team roles](#roles-local) and [decision +making](#decisions) that are needed for project governance or **apply to all +sub-projects** as stated in those sections). +- 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 [project team +roles](#roles-local) and [decision making](#decisions). These sections define +the **gold standard** 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. +- Changes to existing global namespace policies (e.g. [Mailing List +Conventions](/help/mailing-list/100-misc/139-mailing-list-conventions.html)) +and creation of new project wide namespace policies. +- 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. + +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: + + ----------------------------------------------------------------------------------------- + **Proposal** **Who reviews?** **Who votes?** + ----------------------------- ----------------------------- ----------------------------- + Creating, graduating, Members of developer mailing Leadership teams of + completing/archiving of lists of qualifying projects **mature** sub-projects, + 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). + + Global Process Changes Members of developer mailing Leadership teams of + lists of qualifying projects **mature** sub-projects, + within the scope described + above. + ----------------------------------------------------------------------------------------- + The community manager first arranges a public review, followed by a timed private vote. Public review and voting should be open for a minimum of a week each. For voting a traceable poll mechanism (e.g. voting form that keeps -auditable and tamper proof records) must be used. Voting follows the -conventions as laid out in "Principle: Consensus Decision Making". - -Project Governance {#project-governance} +auditable and tamper proof records) must be used. + +Voting is conducted **per project** in line with the following rules: + +- Each qualifying project's vote is counted per project and then aggregated +as outlined below. +- Project leadership team members vote for or against a proposal (there is no +differentiation between **-1**/**-2** and **+1**/**+2**). A **0** vote is not +counted as a valid vote. +- A **quorum of at least least 1/3 of positive votes** of each project's +leadership team members is required. In other words: if a project's leadership +team does not achieve the quorum, the entire sub-project's vote is not counted. +This avoids situations where only a minority of leadership team members vote, +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 +community manager. + +__Passed/Failed Resolutions:__ + +- 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. +- 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). +- 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%). +- If the total vote achieves a 2/3rd majority in favour, the proposal passes. +Otherwise it fails. + +Community Decisions with Funding and Legal Implications {#funding-and-legal} +------------------------------------------------------- +In some cases sub-project local and global decisions **may require +input** from the [Advisory Board](#roles-ab) and/or the [Linux Foundation] +(#roles-lf). For example, if a proposal by a project leadership team or +a global project decision requires that the project hires a staff member or +contractor (e.g. a PR consultant, marketing manager) or requires the funding +of new infrastructure (e.g. additional test hardware or services) to implement +said proposal, then funding would need to be secured from the Advisory Board or +from other sources. + +If for example, a community proposal required the Linux Foundation to sign +a legal agreement with a 3rd party on behalf of the project/sub-project, then +of course a review of such an agreement and a signature by the Linux Foundation +would be required. + +In such cases, the impacted project leadership team(s) will contact the +Community Manager and/or Advisory Board to resolve possible issues. + +Project Governance {#project-governance} ------------------ ### Basic Project Life Cycle @@ -345,7 +672,7 @@ After a review, the requester of the review may decide to withdraw, request a re-review or progress to a vote by arranging with the community manager. **Voting:** The community manager arranges a timed private vote as outlined in -[Formal Votes](#formal-votes). +[Formal Votes](#project-decisions). ### Forming a Project @@ -445,6 +772,10 @@ bugs - It has an active developer community (as we get more experience we will add some guidelines). But things to look for are number of maintainers, different organisations involved, number of users, etc. +- It has a project leadership team that resolves conflicts and participates +in cross-project decision making +- It adheres to the Xen Project governance as outlined in this document, or +documents areas where the sub-project differs Other items to look at during the review (depending on project are): @@ -454,7 +785,8 @@ Other items to look at during the review (depending on project are): ### Mature Projects -Mature projects are expected to be run and promote themselves. The project lead +Mature projects are expected to be run and promote themselves. The project +leadership team and/or 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 @@ -479,7 +811,7 @@ words it has completed In the first case the review is triggered by the incubation project's mentor. Failing this the review can be requested by any maintainer of a mature project -(including the project's lead) or by the Xen Project community manager. See +(including the project’s lead) or by the Xen Project community manager. See "Requesting Reviews, Reviews and Voting". The review is essentially a pitch why the project should be archived. The @@ -511,28 +843,62 @@ Xenproject.org, the code will be remove the code in a subsequent release (it should however give users sufficient time to adapt) -### Exceptional Circumstances +### Exceptional Circumstances {#exceptional-circumstances} -#### Projects without Project Lead +#### Incubation Projects without Project Lead -Projects which lose their project lead during the incubation or maturity phase -are at risk of failing. Should this occur, the project's maintainer community -should agree who would want to be/be able to be the new project lead and follow -the election process as outlined in "Electing Maintainers". +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 +[elections](#elections). 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. +successor we assume that the project does not have enough momentum and will +consider archiving the project. + +#### Projects without functional Project Leadership Team + +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 [elections](#elections). + +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. #### Incubation projects without Mentor Should an incubation project lose its mentor, the Xen Project community manager will support the project lead in finding a new mentor. +Per Sub-Project Governance Specialisation {#specialisations} +----------------------------------------- + +Add specialisations to this section, as they surface. + Change History -------------- -- **v3.0 July 2016:** TODO: Add real changelog in main patch +- **v3.0 December 2016:** Refactored document. Otherwise significant changes to +decision making, in the following areas + - Added Goal: Local Decision Making + - Split roles into project wide and sub-project specific roles + - Added new roles: Community Manager, Security Response Team, Leadership Team + - Added RTC Policy + - Added +2 ... -2 scheme for expressing opinions more clearly + - Clarified lazy consensus / lazy voting with examples + - Added Informal Votes or Surveys + - Added Project Team Leadership decisions (majority vote, non-monotonicity) + - Clarified and Adapted Conflict Resolution to previous changes + - Updated Elections to cover new roles and terminology + - Changed Project Wide Decision making (per project, non-monotonicity) + - Changed Project Wide Decision making. + - Clarified scope of Decision making + - Added section on Community Decisions with Funding and Legal Implications + - Modified all other sections which have dependencies on changes above + - Added Per Sub-Project Governance Specialisation - **v2.1 May 2016:** Clarify Committer Elections as per this [discussion](http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg0080 1.html) and @@ -558,6 +924,4 @@ from Requesting Reviews, Reviews and Voting rather than duplicating - Clarified the roles of Committer and Maintainer. - Added Making Contributions which contains links to other documentation and highlights that Xen.org required a DCO for contributions since 2005. -- **v1.0 Jun 2011:** Initial document approved - - \ No newline at end of file +- **v1.0 Jun 2011:** Initial document approved \ No newline at end of file
List of changes - Added Goal: Local Decision Making - Split roles into project wide and sub-project specific roles - Added new roles: Community Manager, Security Response Team, Leadership Team - Added RTC Policy - Added +2 ... -2 scheme for expressing opinions more clearly - Clarified lazy consensus / lazy voting with examples - Added Informal Votes or Surveys - Added Project Team Leadership decisions (majority vote, non-monotonicity) - Clarified and Adapted Conflict Resolution to previous changes - Updated Elections to cover new roles and terminology - Changed Project Wide Decision making (per project, non-monotonicity) - Clarified scope of Decision making - Added section on Community Decisions with Funding and Legal Implications - Modified all other sections which have dependencies on changes above - Added Per Sub-Project Governance Specialisation - Fixed various typos - Fixed changelog Signed-off-by: Lars Kurth <lars.kurth@citrix.com> --- governance.pandoc | 628 ++++++++++++++++++++++++++++++++++++++++++------------ 1 file changed, 496 insertions(+), 132 deletions(-)