From patchwork Fri Sep 23 18:55:26 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Lars Kurth X-Patchwork-Id: 9348609 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 781F6607D0 for ; Fri, 23 Sep 2016 18:57:53 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 6290B2AD64 for ; Fri, 23 Sep 2016 18:57:53 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 56D212AD74; Fri, 23 Sep 2016 18:57:53 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 6A5ED2AD64 for ; Fri, 23 Sep 2016 18:57:52 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bnVdU-0006W4-VF; Fri, 23 Sep 2016 18:55:48 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bnVdT-0006S9-TU; Fri, 23 Sep 2016 18:55:48 +0000 Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id BE/59-23620-2BA75E75; Fri, 23 Sep 2016 18:55:46 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRWlGSWpSXmKPExsWS0XRdVXdj1dN wg5ULzS16W++yWPxZnGjxZXkDo8X3LZOZHFg8Dn+4whLAGMWamZeUX5HAmnHz9nzWgjPZFdPP HGVpYNwd2cXIxSEkcJJR4sCidjYI5yKjxK/p/5m7GDk52AQ0JI49bAazRQSUJO6tmswEUsQss JpRYvqeg2wgCWEBf4kDLX/ZQWwWAVWJvoatrCA2r4CLxOqv81hAbAkBXYm7Ny+AxTkFXCWOvj sB1isEVDPjzTn2CYzcCxgZVjGqF6cWlaUW6ZrqJRVlpmeU5CZm5ugaGhjr5aYWFyemp+YkJhX rJefnbmIEer+egYFxB+Plr06HGCU5mJREeZXcnoYL8SXlp1RmJBZnxBeV5qQWH2KU4eBQkuB1 MADKCRalpqdWpGXmAMMQJi3BwaMkwju9EijNW1yQmFucmQ6ROsWoKCXOywuSEABJZJTmwbXBQ v8So6yUMC8jAwODEE9BalFuZgmq/CtGcQ5GJWHeVpApPJl5JXDTXwEtZgJa/O3OE5DFJYkIKa kGxoorSS3Bx+LuK/nZb1X/f2r3J/dd5n4PF2j38S/7nH1aSWTqQ56CoJjtHytPTw69fiW+/zz 7o+1/40/8koh1zMrKX+8VGzPB/sDH7idFV6K0TrrITvD25S8+e2V3REVSio79vWuS3z65SMze NMu/8trdO7ecz7kJbrhQdGeT7Zr3R873pE5ee1WJpTgj0VCLuag4EQDppaXfeAIAAA== X-Env-Sender: lars.kurth@citrix.com X-Msg-Ref: server-11.tower-31.messagelabs.com!1474656944!31512809!1 X-Originating-IP: [104.130.215.37] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 8.84; banners=-,-,- X-VirusChecked: Checked Received: (qmail 48460 invoked from network); 23 Sep 2016 18:55:45 -0000 Received: from mail.xenproject.org (HELO mail.xenproject.org) (104.130.215.37) by server-11.tower-31.messagelabs.com with AES128-GCM-SHA256 encrypted SMTP; 23 Sep 2016 18:55:45 -0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bnVdK-0003aF-DZ; Fri, 23 Sep 2016 18:55:38 +0000 Received: from localhost ([127.0.0.1] helo=MacBook-Pro-6.Home) by xenbits.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bnVdJ-00056l-Px; Fri, 23 Sep 2016 18:55:38 +0000 From: Lars Kurth To: xen-devel@lists.xenproject.org Date: Fri, 23 Sep 2016 19:55:26 +0100 Message-Id: <1474656929-3528-2-git-send-email-lars.kurth@citrix.com> X-Mailer: git-send-email 2.5.4 (Apple Git-61) In-Reply-To: <1474656929-3528-1-git-send-email-lars.kurth@citrix.com> References: <1474656929-3528-1-git-send-email-lars.kurth@citrix.com> Cc: xen-api@lists.xenproject.org, win-pv-devel@lists.xenproject.org, committers@xenproject.org, mirageos-devel@lists.xenproject.org, Lars Kurth Subject: [Xen-devel] [PATCH v3 1/4] Code motion changes to make real patches easier to read X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" X-Virus-Scanned: ClamAV using ClamSMTP 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 Reviewed-by: Konrad Rzeszutek Wilk --- 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