Xen project Mailing List

Re: [Xen-API] [PATCH v3 1/4] Code motion changes to make real patches easier to read

On Fri, Sep 23, 2016 at 07:55:26PM +0100, Lars Kurth wrote: > Added TOC > Re-arranged sections compared to previous version of document > Added new anchors where needed > Split Roles section into two sections > > The actual content was not changed (with the exception of minor > typos that I spotted) > > Signed-off-by: Lars Kurth <lars.kurth@xxxxxxxxxx> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> > --- > governance.pandoc | 207 > +++++++++++++++++++++++++++++------------------------- > 1 file changed, 113 insertions(+), 94 deletions(-) > > diff --git a/governance.pandoc b/governance.pandoc > index 60fc942..2ce780c 100644 > --- a/governance.pandoc > +++ b/governance.pandoc > @@ -1,9 +1,20 @@ > - > -This document has come in effect in June 2011 and will be > -reviewed periodically (see revision sections). The last modification has > been > -made in May 2013. > - > -Goals > +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. > + > +Content > +------- > + > +- [Goals](#goals) > +- [Principles](#principles) > +- [Xen Project Wide Roles](#roles-global) > +- [Project Team Roles](#roles-local) > +- [Making Contributions](#contributions) > +- [Decision Making, Conflict Resolution, Role Nominations and > +Elections](#decisions) > +- [Formal Votes](#formal-votes) > +- [Project Governance](#project-governance) > + > +Goals {#goals} > ----- > > The goals of Xen Project Governance are to: > @@ -22,7 +33,7 @@ going elsewhere > - Set clear expectations to vendors, upstream and downstream projects and > community members > > -Principles > +Principles {#principles} > ---------- > > ### Openness > @@ -43,71 +54,8 @@ 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. > > -### 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 > - > -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 > - > -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. > - > -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. > - > -Roles > ------ > - > -### 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. > - > -### Committers > - > -Committers are Maintainers that are allowed to commit changes into the > source > -code repository. The committer acts on the wishes of the maintainers and > -applies changes that have been approved by the respective maintainer(s) to > the > -source tree. Due to their status in the community, committers can also act > as > -referees should disagreements amongst maintainers arise. Committers are > listed > -on the sub-project's team portal (e.g. [Hypervisor team > -portal](/developers/teams/hypervisor.html)). > +Xen Project Wide Roles {#roles-global} > +---------------------- > > ### Sub-projects and Teams > > @@ -118,16 +66,6 @@ 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. > > -### Project Lead > - > -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. > - > ### Xen Project Advisory Board > > The [Xen Project Advisory Board](/join.html) consists of members who are > @@ -162,7 +100,38 @@ 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. > > -Making Contributions > +Project Team Roles {#roles-local} > +------------------ > + > +### 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. > + > +### Committers > + > +Committers are Maintainers that are allowed to commit changes into the > source > +code repository. The committer acts on the wishes of the maintainers and > +applies changes that have been approved by the respective maintainer(s) to > the > +source tree. Due to their status in the community, committers can also act > as > +referees should disagreements amongst maintainers arise. Committers are > listed > +on the sub-project's team portal (e.g. [Hypervisor team > +portal](/developers/teams/hypervisor.html)). > + > +### Project Lead > + > +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. > + > +Making Contributions {#contributions} > -------------------- > > Making contributions in Xen follows the conventions as they are known in the > @@ -176,12 +145,60 @@ > Origin](http://elinux.org/Developer_Certificate_Of_Origin)). > More information on making contributions can be found in the following > documents: > > -- [Contribution Guidelines](g/help/contribution-guidelines.html) > +- [Contribution Guidelines](/help/contribution-guidelines.html) > + > +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 > + > +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 > + > +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. > + > +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. > > -Elections and Formal Votes > --------------------------- > +### Elections > > -### Maintainer 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 > @@ -199,7 +216,7 @@ 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. > > -### Committer Elections > +#### Committer 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 > @@ -219,21 +236,22 @@ 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. > > -### Project Lead Elections > +#### 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 {#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**). > +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 > @@ -263,7 +281,7 @@ 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 {#project-governance} > ------------------ > > ### Basic Project Life Cycle > @@ -461,7 +479,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 projec'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 > @@ -514,6 +532,7 @@ will support the project lead in finding a new mentor. > Change History > -------------- > > +- **v3.0 July 2016:** TODO: Add real changelog in main patch > - **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 > @@ -539,6 +558,6 @@ 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:** Intial document approved > +- **v1.0 Jun 2011:** Initial document approved > > > \ No newline at end of file > -- > 2.5.4 (Apple Git-61) > _______________________________________________ Xen-api mailing list Xen-api@xxxxxxxxxxxxx https://lists.xen.org/cgi-bin/mailman/listinfo/xen-api

©2013 Xen Project, A Linux Foundation Collaborative Project. All Rights Reserved.
Linux Foundation is a registered trademark of The Linux Foundation.
Xen Project is a trademark of The Linux Foundation.