[Xen-devel] [PATCH 3/3] Significant changes to decision making; some new roles and minor changes
Added RTC Policy
Added +2 ... -2 scheme for votes
Clarified lazy consensus
Added Informal Votes/Surveys
Added Project Team Leadership role and Decision making
Changed Project Wide Decision making: per project based scheme
Clarified scope of Decision making
Modified sections which have dependencies on changes about
Signed-off-by: Lars Kurth
---
governance.pandoc | 714 --
1 file changed, 535 insertions(+), 179 deletions(-)
diff --git a/governance.pandoc b/governance.pandoc
index 86e4433..b824c7f 100644
--- a/governance.pandoc
+++ b/governance.pandoc
@@ -1,4 +1,3 @@
-
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.
@@ -12,8 +11,9 @@ Content
- [Making Contributions](#contributions)
- [Decision Making, Conflict Resolution, Role Nominations and
Elections](#decisions)
-- [Formal Votes](#formal-votes)
+- [Project Wide Decision Making](#project-decisions)
- [Project Governance](#project-governance)
+- [Per Sub-Project Governance Specialisations](#specialisations)
Goals {#goals}
-
@@ -55,23 +55,17 @@ 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.
-
+### Local Decision Making
+
-
-I moved the "Roles" section up and split it into two sections with
unmodified content
-- Xen Project Wide Roles
-- Project Team Roles
+This is a little clumsy: maybe someone can come up with a better definition
-
-Xen Project Wide Roles {#roles-global}
+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}
--
-
-
-
-MINOR ISSUES TO BE ADDRESSED LATER:
-- Sub-projects and Teams would benefit from some forward references to
highlight the
- difference between incubation mature projects.
-- Also we should clarify what assets a sub-project owns.
-- Add the role of Community Manager as it used throughout the document
-
-
### Sub-projects and Teams
@@ -80,7 +74,20 @@ 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
+
+The Xen Project has a community manager, whose primary role it is to support
+the entire Xen Project Community.
### Xen Project Advisory Board
@@ -111,30 +118,60 @@ 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}
--
-
-
-ISSUES TO BE ADDRESSED LATER:
-- Fix minor Inaccuracies and Improvements
-- Allow for customization of roles by sub-projects (but this definition is
the default)
-- Allow for Security Response Team
-- Allow for sub-projects to be lead by a Project Leadership Team (which
may include a
- Project Lead)
-
--
Re: [Xen-devel] [PATCH 3/3] Significant changes to decision making; some new roles and minor changes
On 16/08/2016 06:32, "Tim Deegan" wrote: >Hi, > >At 14:55 + on 15 Aug (1471272946), Lars Kurth wrote: >> But I see your point. The text should really have said something like... >> - >> In situations where the entire Xen Project community becomes paralysed, >> the project leaderships team or project lead should work with the >> community >> manager or advisory board to find a way forward. >> - > >Sure. I think that's good. > >> I think we have two options: >> A) A delete this bullet entirely >> B) Replace it with something clearer - even though, the location >> for such a paragraph is wrong. >> >> My gut feel is to just go for A. > >Sounds good to me. Having looked at the text again (making edits for v2), I propose to add the following new section to the document. - - [Community Decisions with Funding and Legal implications](#funding-and-legal) ... 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. - I don't think this is in fact a change in governance. It is just clarifying what has happened in the past. I merely wanted to highlight that in some cases there are dependencies. We have not had any global changes, where this was the case, but we had a few local ones. E.g. - Windows driver signing required buying a cert and an agreement between the LF and Microsoft to deliver signed windows drivers - The way how we make hypervisor releases requires to operate OSSTEST (aka. COLO agreements, procurement of HW, technical support, ...) which also required the LF to sign contracts on behalf of the project. I hope that is OK Best Regards Lars ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/3] Significant changes to decision making; some new roles and minor changes
At 11:56 + on 09 Sep (1473422177), Lars Kurth wrote: > 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. > > > - FWIW, LGTM. Cheers, Tim. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/3] Significant changes to decision making; some new roles and minor changes
>>> On 12.08.16 at 01:13, wrote:
> +### Lazy Consensus {#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 decison (see below). Lazy Consensus is extremely useful, when you
> don't
> +anticipate any objections, or to gage whether there are objections to a
> +proposal. To make use of it, post something like the following on the
> project's
> +mailing list (or some other communication channel):
>
>
> -
> -ISSUES TO BE ADDRESSED LATER:
> -- The "Consensus Decision Making" section is totally wrong. It does not
> describe
> - "Lazy Consensus"
> +Should we set a fixed time-frame? If so what?
>
> -
>
> -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.
> +> 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:__
> +
> +- Failed: A single **-2** by a stake-holder whose approval is necessary
> +- Failed: **-1**'s by all stake-holder whose approval is necessary
> +- Passed: In all other situations
Hmm, that means all -1's except a single 0 would already be a pass?
> +Let me express this as an algorithm.
> +
> + treshhold=2/3;
> + active='number of active members'; (7 for the Hypervisor project; IanC
> is inactive)
> + favour='number of +1 and +2 votes'
> + against='number of -1 and -2 votes'
> + strong-against='number -2 votes'; just added this as a sanity check
> +
> +One open question is what to do with 0-votes. We could introduce a rule
> discounting
> +0 votes (let's call it 0-rule). If someone votes 0, we assume they
> really don't care
> +about the outcome and are considered inactive for the purpose of the
> vote.
> +
> +In that case:
> +
> + active -= 0-votes;
> +
> +Without the 0-rule:
> +- to pass: favour/active >= treshhold
> + to pass: with active==7, favour >= 5
> + in other words, 3 (0,-1,-2)-votes block the proposal as we cant
> achieve favour>=5
> +
> +With the 0-rule, let's consider 1, 2 or 3 0-votes
> +1=>6: to pass: favour >=4
> + in other words, 3 (-1,-2)-votes block the proposal
> +2=>5: to pass: favour >=4
> + in other words, 2 (-1,-2)-vote blocks the proposal
> +3=>4: to pass: favour >=3
> + in other words, 2 (-1,-2)-vote blocks the proposal
> +
> +Looking at the arithmetic, it does probably make sense to go for the
> 0-rule. If we
> +do, there ought to be more votes in favour of a proposal, than 0-votes.
> +
> +On the other hand, not having the 0-rule forces everyone to form an
> opinion,
> +otherise we will find it hard to make decisions. But in some cases,
> forming an
> +opinion costs significant mental capacity.
> +
> +It would also allow us to remove the complexity of differentiating
> between
> +active and non-active leadership team members by assuming that no vote,
> equals
> +a "0" vote.
> +
> +Opinions?
I'm in favor of the "with 0-rule" variant.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/3] Significant changes to decision making; some new roles and minor changes
On 12/08/2016 13:41, "Jan Beulich" wrote:
On 12.08.16 at 01:13, wrote:
>> +### Lazy Consensus {#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 decison (see below). Lazy Consensus is extremely useful, when
>>you don't
>> +anticipate any objections, or to gage whether there are objections to
>>a
>> +proposal. To make use of it, post something like the following on the
>>project's
>> +mailing list (or some other communication channel):
>>
>>
>>-
>>
>> -ISSUES TO BE ADDRESSED LATER:
>> -- The "Consensus Decision Making" section is totally wrong. It
>>does not describe
>> - "Lazy Consensus"
>> +Should we set a fixed time-frame? If so what?
>>
>>-
>>
>>
>> -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.
>> +> 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:__
>> +
>> +- Failed: A single **-2** by a stake-holder whose approval is
>>necessary
>> +- Failed: **-1**'s by all stake-holder whose approval is necessary
>> +- Passed: In all other situations
>
>Hmm, that means all -1's except a single 0 would already be a pass?
That is not the intention. If we have only -1's and 0's it should be a
fail.
Let me fix this in the next revisions.
How about:
+- Failed: Only **-1** or **0** votes by all stake-holder whose approval
is necessary
Although maybe someone can come up with a clearer way to express this.
>> +Let me express this as an algorithm.
>> +
>> + treshhold=2/3;
>> + active='number of active members'; (7 for the Hypervisor
>>project; IanC is inactive)
>> + favour='number of +1 and +2 votes'
>> + against='number of -1 and -2 votes'
>> + strong-against='number -2 votes'; just added this as a sanity
>>check
>> +
>> +One open question is what to do with 0-votes. We could introduce a
>>rule discounting
>> +0 votes (let's call it 0-rule). If someone votes 0, we assume they
>>really don't care
>> +about the outcome and are considered inactive for the purpose of
>>the vote.
>> +
>> +In that case:
>> +
>> + active -= 0-votes;
>> +
>> +Without the 0-rule:
>> +- to pass: favour/active >= treshhold
>> + to pass: with active==7, favour >= 5
>> + in other words, 3 (0,-1,-2)-votes block the proposal as we cant
>>achieve favour>=5
>> +
>> +With the 0-rule, let's consider 1, 2 or 3 0-votes
>> +1=>6: to pass: favour >=4
>> + in other words, 3 (-1,-2)-votes block the proposal
>> +2=>5: to pass: favour >=4
>> + in other words, 2 (-1,-2)-vote blocks the proposal
>> +3=>4: to pass: favour >=3
>> + in other words, 2 (-1,-2)-vote blocks the proposal
>> +
>> +Looking at the arithmetic, it does probably make sense to go for
>>the 0-rule. If we
>> +do, there ought to be more votes in favour of a proposal, than
>>0-votes.
>> +
>> +On the other hand, not having the 0-rule forces everyone to form
>>an opinion,
>> +otherise we will find it hard to make decisions. But in some
>>cases, forming an
>> +opinion costs significant mental capacity.
>> +
>> +It would also allow us to remove the complexity of differentiating
>>between
>> +active and non-active leadership team members by assuming that no
>>vote, equals
>> +a "0" vote.
>> +
>> +Opinions?
>
>I'm in favor of the "with 0-rule" variant.
That's what I assumed most people would go for and which is (hopefully
correctly)
implemented in the rules above the comment section.
Regards
Lars
___
Xen-devel mailing list
Xen-devel@lists.x
Re: [Xen-devel] [PATCH 3/3] Significant changes to decision making; some new roles and minor changes
>>> On 12.08.16 at 14:53, wrote:
> On 12/08/2016 13:41, "Jan Beulich" wrote:
> On 12.08.16 at 01:13, wrote:
>>> +### Lazy Consensus {#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 decison (see below). Lazy Consensus is extremely useful, when
>>>you don't
>>> +anticipate any objections, or to gage whether there are objections to
>>>a
>>> +proposal. To make use of it, post something like the following on the
>>>project's
>>> +mailing list (or some other communication channel):
>>>
>>>
>>>-
>>>
>>> -ISSUES TO BE ADDRESSED LATER:
>>> -- The "Consensus Decision Making" section is totally wrong. It
>>>does not describe
>>> - "Lazy Consensus"
>>> +Should we set a fixed time-frame? If so what?
>>>
>>>-
>>>
>>>
>>> -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.
>>> +> 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:__
>>> +
>>> +- Failed: A single **-2** by a stake-holder whose approval is
>>>necessary
>>> +- Failed: **-1**'s by all stake-holder whose approval is necessary
>>> +- Passed: In all other situations
>>
>>Hmm, that means all -1's except a single 0 would already be a pass?
>
> That is not the intention. If we have only -1's and 0's it should be a
> fail.
> Let me fix this in the next revisions.
>
> How about:
> +- Failed: Only **-1** or **0** votes by all stake-holder whose approval
> is necessary
That would still leave 10 -1's overruled by a single +1.
> Although maybe someone can come up with a clearer way to express this.
Maybe when there are no +2's, simply take the sum of all votes,
and require it to be non-negative?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/3] Significant changes to decision making; some new roles and minor changes
On Fri, 12 Aug 2016, Jan Beulich wrote: > > +Let me express this as an algorithm. > > + > > + treshhold=2/3; > > + active='number of active members'; (7 for the Hypervisor project; > > IanC is inactive) > > + favour='number of +1 and +2 votes' > > + against='number of -1 and -2 votes' > > + strong-against='number -2 votes'; just added this as a sanity check > > + > > +One open question is what to do with 0-votes. We could introduce a > > rule discounting > > +0 votes (let's call it 0-rule). If someone votes 0, we assume they > > really don't care > > +about the outcome and are considered inactive for the purpose of the > > vote. > > + > > +In that case: > > + > > + active -= 0-votes; > > + > > +Without the 0-rule: > > +- to pass: favour/active >= treshhold > > + to pass: with active==7, favour >= 5 > > + in other words, 3 (0,-1,-2)-votes block the proposal as we cant > > achieve favour>=5 > > + > > +With the 0-rule, let's consider 1, 2 or 3 0-votes > > +1=>6: to pass: favour >=4 > > + in other words, 3 (-1,-2)-votes block the proposal > > +2=>5: to pass: favour >=4 > > + in other words, 2 (-1,-2)-vote blocks the proposal > > +3=>4: to pass: favour >=3 > > + in other words, 2 (-1,-2)-vote blocks the proposal > > + > > +Looking at the arithmetic, it does probably make sense to go for the > > 0-rule. If we > > +do, there ought to be more votes in favour of a proposal, than 0-votes. > > + > > +On the other hand, not having the 0-rule forces everyone to form an > > opinion, > > +otherise we will find it hard to make decisions. But in some cases, > > forming an > > +opinion costs significant mental capacity. > > + > > +It would also allow us to remove the complexity of differentiating > > between > > +active and non-active leadership team members by assuming that no > > vote, equals > > +a "0" vote. > > + > > +Opinions? > > I'm in favor of the "with 0-rule" variant. I am also in favor of the 0-rule ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/3] Significant changes to decision making; some new roles and minor changes
On 12/08/2016 14:01, "Jan Beulich" wrote:
On 12.08.16 at 14:53, wrote:
>> On 12/08/2016 13:41, "Jan Beulich" wrote:
>> On 12.08.16 at 01:13, wrote:
+### Lazy Consensus {#lazyconsensus}
+
[snip]
+
+Objections by stake-holders should be expressed using the
[conventions
+above](#expressingopinion) to make disagreements easily identifiable.
+
+__Passed/Failed:__
+
+- Failed: A single **-2** by a stake-holder whose approval is
necessary
+- Failed: **-1**'s by all stake-holder whose approval is necessary
+- Passed: In all other situations
>>>
>>>Hmm, that means all -1's except a single 0 would already be a pass?
>>
>> That is not the intention. If we have only -1's and 0's it should be a
>> fail.
>> Let me fix this in the next revisions.
>>
>> How about:
>> +- Failed: Only **-1** or **0** votes by all stake-holder whose
>>approval
>> is necessary
>
>That would still leave 10 -1's overruled by a single +1.
>
>> Although maybe someone can come up with a clearer way to express this.
>
>Maybe when there are no +2's, simply take the sum of all votes,
>and require it to be non-negative?
That would work. Any other opinions?
Lars
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/3] Significant changes to decision making; some new roles and minor changes
Hi,
At 00:13 +0100 on 12 Aug (1470960826), Lars Kurth wrote:
> +### 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, 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.
> +
> +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.
> +
> +In situations where there is significant disagreement between sub-projects,
> the
> +issue is deferred to the [Xen Project Advisory Board](/join.html).
This looks like a pretty significant shift of responsibilty to the AB.
As I read it, the current governance requires a _vote_ if subprojects
disagree, with the AB only called to break a tie.
It also seems to conflict with the wording that the AB "leaves all
technical decisions to the open source meritocracy".
IMO if this is to be changed it should be to something more concrete
than "significant disagreement".
> +- Some sections of this document such as [Xen Project wide
> +roles](#roles-global) and [making contributions](#contributions) **cannot be
> +changed by the community** without obtaining additional approval from the
> +Advisory Board and/or the Linux Foundation, if these conflict requirements
> that
> +stem from being part of a Linux Foundation Collaborative Project (e.g
> requiring
> +a contributor license agreement). Areas with such requirements cover
> +trademarks, legal oversight, financial oversight and project funding.
Again, this is a change from the current governance, which just
delegates those things to the AB and leaves it at that (with the
implication that the project as a whole controls its own governance).
IMO it would be better to leave the AB wording as it is, and refer to
a _specific_ LF policy document in the section on the LF.
Or if people want a section like this then it should be a clear list
of exactly which things require approval from which bodies, with no
"such as" or similar, so there is no confusion later.
Cheers,
Tim.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/3] Significant changes to decision making; some new roles and minor changes
Hi Tim,
>At 00:13 +0100 on 12 Aug (1470960826), Lars Kurth wrote:
>> +### 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, 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.
>> +
>> +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.
>> +
>> +In situations where there is significant disagreement between
>>sub-projects, the
>> +issue is deferred to the [Xen Project Advisory Board](/join.html).
>
>This looks like a pretty significant shift of responsibilty to the AB.
>As I read it, the current governance requires a _vote_ if subprojects
>disagree, with the AB only called to break a tie.
>
>It also seems to conflict with the wording that the AB "leaves all
>technical decisions to the open source meritocracy".
>
>IMO if this is to be changed it should be to something more concrete
>than "significant disagreement".
That was not intentional. It crept in, because I wanted to avoid repeating
the phrase I used in the previous paragraph, purely for style reasons.
A bit of background on my thinking
A) The AB never felt comfortable with the tie-breaker scenario
B) The new voting model doesn't require the AB to be a tie maker any more
C) It does spell out the areas where AB sign-off is needed regardless of
Community votes more clearly (in practice mostly it will primarily in
areas where funds are needed to implement something)
See your comment below
D) Also, from a scope perspective, global votes would only ever be about
non-technical issues, such as policy
But I see your point. The text should really have said something like...
-
In situations where the entire Xen Project community becomes paralysed,
the project leaderships team or project lead should work with the
community
manager or advisory board to find a way forward.
-
It would be nice to list an examples of "becoming paralysed", but
I can't think of anything.
>> +- Some sections of this document such as [Xen Project wide
>> +roles](#roles-global) and [making contributions](#contributions)
>>**cannot be
>> +changed by the community** without obtaining additional approval from
>>the
>> +Advisory Board and/or the Linux Foundation, if these conflict
>>requirements that
>> +stem from being part of a Linux Foundation Collaborative Project (e.g
>>requiring
>> +a contributor license agreement). Areas with such requirements cover
>> +trademarks, legal oversight, financial oversight and project funding.
>
>Again, this is a change from the current governance, which just
>delegates those things to the AB and leaves it at that (with the
>implication that the project as a whole controls its own governance).
I can see how this comes across. I will lay out my thoughts after answering
your other concerns.
>IMO it would be better to leave the AB wording as it is, and refer to
>a _specific_ LF policy document in the section on the LF.
I am lost now: there is not much wording related to the Advisory Board
in the original governance at all (except where the AB is defined). I
could
take this entire paragraph out, as in fact we did not have it and we
Managed well. In practice, people would just come to me when there were
grey
areas.
>
>Or if people want a section like this then it should be a clear list
>of exactly which things require approval from which bodies, with no
>"such as" or similar, so there is no confusion later.
That's a problem, because there are no public documents listing these.
For example, there is no published document which says, collaborative
Projects must not have a CLA. But we were told that me must never
introduce one, when we became an LF project.
I put this section in, because in practice community members do tend
to come to me (as member of the AB) when it comes to funding stuff: e.g.
build and CI infra for the Win PV driver project, ... but these were
project local things. And we had past instances when an AB member
raised concrete issues (e.g. in 2012 a number of contributors were really
Unhappy that we didn't have a release and roadmap process). But in
hindsight,
This paragraph doesn't add much and isn't really needed.
I think we have two options:
Re: [Xen-devel] [PATCH 3/3] Significant changes to decision making; some new roles and minor changes
Hi, At 14:55 + on 15 Aug (1471272946), Lars Kurth wrote: > But I see your point. The text should really have said something like... > - > In situations where the entire Xen Project community becomes paralysed, > the project leaderships team or project lead should work with the > community > manager or advisory board to find a way forward. > - Sure. I think that's good. > I think we have two options: > A) A delete this bullet entirely > B) Replace it with something clearer - even though, the location > for such a paragraph is wrong. > > My gut feel is to just go for A. Sounds good to me. Cheers, Tim. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/3] Significant changes to decision making; some new roles and minor changes
On Sat, Aug 13, 2016 at 09:28:49AM +, Lars Kurth wrote:
>
>
> On 12/08/2016 14:01, "Jan Beulich" wrote:
>
> On 12.08.16 at 14:53, wrote:
> >> On 12/08/2016 13:41, "Jan Beulich" wrote:
> >> On 12.08.16 at 01:13, wrote:
> +### Lazy Consensus {#lazyconsensus}
> +
> [snip]
> +
> +Objections by stake-holders should be expressed using the
> [conventions
> +above](#expressingopinion) to make disagreements easily identifiable.
> +
> +__Passed/Failed:__
> +
> +- Failed: A single **-2** by a stake-holder whose approval is
> necessary
> +- Failed: **-1**'s by all stake-holder whose approval is necessary
> +- Passed: In all other situations
> >>>
> >>>Hmm, that means all -1's except a single 0 would already be a pass?
> >>
> >> That is not the intention. If we have only -1's and 0's it should be a
> >> fail.
> >> Let me fix this in the next revisions.
> >>
> >> How about:
> >> +- Failed: Only **-1** or **0** votes by all stake-holder whose
> >>approval
> >> is necessary
> >
> >That would still leave 10 -1's overruled by a single +1.
> >
> >> Although maybe someone can come up with a clearer way to express this.
> >
> >Maybe when there are no +2's, simply take the sum of all votes,
> >and require it to be non-negative?
>
> That would work. Any other opinions?
When there are no +2's *and -2's* ?
> Lars
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/3] Significant changes to decision making; some new roles and minor changes
On Fri, Aug 12, 2016 at 12:13:46AM +0100, Lars Kurth wrote: [...] > +The table below maps active votes against votes needed to pass: > + > + --- -- -- -- -- -- -- -- -- > + **Active Votes** 10 9 8 7 6 5 4 3 2 > + **+1 votes needed to pass**7 6 6 5 4 4 3 2 2 > + --- -- -- -- -- -- -- -- -- > + > + > - > +This comment section contains some examples that have influenced the > section above. > + > +Let me express this as an algorithm. > + > + treshhold=2/3; > + active='number of active members'; (7 for the Hypervisor project; IanC > is inactive) > + favour='number of +1 and +2 votes' > + against='number of -1 and -2 votes' > + strong-against='number -2 votes'; just added this as a sanity check > + > +One open question is what to do with 0-votes. We could introduce a rule > discounting > +0 votes (let's call it 0-rule). If someone votes 0, we assume they > really don't care > +about the outcome and are considered inactive for the purpose of the > vote. > + > +In that case: > + > + active -= 0-votes; > + > +Without the 0-rule: > +- to pass: favour/active >= treshhold > + to pass: with active==7, favour >= 5 > + in other words, 3 (0,-1,-2)-votes block the proposal as we cant > achieve favour>=5 > + > +With the 0-rule, let's consider 1, 2 or 3 0-votes > +1=>6: to pass: favour >=4 > + in other words, 3 (-1,-2)-votes block the proposal > +2=>5: to pass: favour >=4 > + in other words, 2 (-1,-2)-vote blocks the proposal > +3=>4: to pass: favour >=3 > + in other words, 2 (-1,-2)-vote blocks the proposal > + > +Looking at the arithmetic, it does probably make sense to go for the > 0-rule. If we > +do, there ought to be more votes in favour of a proposal, than 0-votes. > + > +On the other hand, not having the 0-rule forces everyone to form an > opinion, > +otherise we will find it hard to make decisions. But in some cases, > forming an > +opinion costs significant mental capacity. > + > +It would also allow us to remove the complexity of differentiating > between > +active and non-active leadership team members by assuming that no vote, > equals > +a "0" vote. > + > +Opinions? > I'm in favour of having 0-rule here. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/3] Significant changes to decision making; some new roles and minor changes
On 26/08/2016 07:49, "Wei Liu" wrote:
>On Sat, Aug 13, 2016 at 09:28:49AM +, Lars Kurth wrote:
>>
>>
>> On 12/08/2016 14:01, "Jan Beulich" wrote:
>>
>> On 12.08.16 at 14:53, wrote:
>> >> On 12/08/2016 13:41, "Jan Beulich" wrote:
>> >> On 12.08.16 at 01:13, wrote:
>> +### Lazy Consensus {#lazyconsensus}
>> +
>> [snip]
>> +
>> +Objections by stake-holders should be expressed using the
>> [conventions
>> +above](#expressingopinion) to make disagreements easily
>>identifiable.
>> +
>> +__Passed/Failed:__
>> +
>> +- Failed: A single **-2** by a stake-holder whose approval is
>> necessary
>> +- Failed: **-1**'s by all stake-holder whose approval is
>>necessary
>> +- Passed: In all other situations
>> >>>
>> >>>Hmm, that means all -1's except a single 0 would already be a pass?
>> >>
>> >> That is not the intention. If we have only -1's and 0's it should be
>>a
>> >> fail.
>> >> Let me fix this in the next revisions.
>> >>
>> >> How about:
>> >> +- Failed: Only **-1** or **0** votes by all stake-holder whose
>> >>approval
>> >> is necessary
>> >
>> >That would still leave 10 -1's overruled by a single +1.
>> >
>> >> Although maybe someone can come up with a clearer way to express
>>this.
>> >
>> >Maybe when there are no +2's, simply take the sum of all votes,
>> >and require it to be non-negative?
>>
>> That would work. Any other opinions?
>
>When there are no +2's *and -2's* ?
I guess we are a little confused here.
A -2 is a strong objection. So what we are saying is that with a strong
objection we can't move forward. Now we are only using this scheme for
expressing opinion informally and on Lazy Consensus. The central idea
behind Lazy consensus is that WE DO NOT NEED to explicitly express
agreement: in other words, the default when someone does not saying
anything is a +1 (an implicit agreement).
I added the "Only **-1** or **0** votes by all stake-holder whose", as
this would be a strong signal that people generally think we don't have a
good proposal and nobody is willing to defend it in any way.
+2's and -2's are in some sense a way to highlight that we have a strong
disagreement on an issue, whereas if we had +1's to -1's we only have a
minor disagreement.
I am not quite sure how to encode this using a formula. Looking for
feedback, but will do a little research in Apache, Eclipse and other FOSS
projects
Lars
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/3] Significant changes to decision making; some new roles and minor changes
On Fri, Aug 26, 2016 at 03:35:38PM +0100, Lars Kurth wrote:
>
>
> On 26/08/2016 07:49, "Wei Liu" wrote:
>
> >On Sat, Aug 13, 2016 at 09:28:49AM +, Lars Kurth wrote:
> >>
> >>
> >> On 12/08/2016 14:01, "Jan Beulich" wrote:
> >>
> >> On 12.08.16 at 14:53, wrote:
> >> >> On 12/08/2016 13:41, "Jan Beulich" wrote:
> >> >> On 12.08.16 at 01:13, wrote:
> >> +### Lazy Consensus {#lazyconsensus}
> >> +
> >> [snip]
> >> +
> >> +Objections by stake-holders should be expressed using the
> >> [conventions
> >> +above](#expressingopinion) to make disagreements easily
> >>identifiable.
> >> +
> >> +__Passed/Failed:__
> >> +
> >> +- Failed: A single **-2** by a stake-holder whose approval is
> >> necessary
> >> +- Failed: **-1**'s by all stake-holder whose approval is
> >>necessary
> >> +- Passed: In all other situations
> >> >>>
> >> >>>Hmm, that means all -1's except a single 0 would already be a pass?
> >> >>
> >> >> That is not the intention. If we have only -1's and 0's it should be
> >>a
> >> >> fail.
> >> >> Let me fix this in the next revisions.
> >> >>
> >> >> How about:
> >> >> +- Failed: Only **-1** or **0** votes by all stake-holder whose
> >> >>approval
> >> >> is necessary
> >> >
> >> >That would still leave 10 -1's overruled by a single +1.
> >> >
> >> >> Although maybe someone can come up with a clearer way to express
> >>this.
> >> >
> >> >Maybe when there are no +2's, simply take the sum of all votes,
> >> >and require it to be non-negative?
> >>
> >> That would work. Any other opinions?
> >
> >When there are no +2's *and -2's* ?
>
> I guess we are a little confused here.
>
> A -2 is a strong objection. So what we are saying is that with a strong
> objection we can't move forward. Now we are only using this scheme for
> expressing opinion informally and on Lazy Consensus. The central idea
> behind Lazy consensus is that WE DO NOT NEED to explicitly express
> agreement: in other words, the default when someone does not saying
> anything is a +1 (an implicit agreement).
>
> I added the "Only **-1** or **0** votes by all stake-holder whose", as
> this would be a strong signal that people generally think we don't have a
> good proposal and nobody is willing to defend it in any way.
>
> +2's and -2's are in some sense a way to highlight that we have a strong
> disagreement on an issue, whereas if we had +1's to -1's we only have a
> minor disagreement.
>
> I am not quite sure how to encode this using a formula. Looking for
> feedback, but will do a little research in Apache, Eclipse and other FOSS
> projects
>
I wish we can't get into a situation that more than one rule could be
applied. So with your original words, a vote with one -2 and six +1's
(assuming 7 valid votes in total) can have two interpretations.
Failed: A single **-2** by a stake-holder whose approval is necessary
Passed: No +2's but total sum >0
Maybe I missed something here?
Or do you want to explicitly state the precedence of rules?
Wei.
> Lars
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/3] Significant changes to decision making; some new roles and minor changes
On 26/08/2016 10:51, "Wei Liu" wrote: >On Fri, Aug 26, 2016 at 03:35:38PM +0100, Lars Kurth wrote: >> >> >> On 26/08/2016 07:49, "Wei Liu" wrote: >> >> >On Sat, Aug 13, 2016 at 09:28:49AM +, Lars Kurth wrote: >> >> >> >> >> How about: >> >> >> +- Failed: Only **-1** or **0** votes by all stake-holder whose >> >> >>approval >> >> >> is necessary >> >> > >> >> >That would still leave 10 -1's overruled by a single +1. >> >> > >> >> >> Although maybe someone can come up with a clearer way to express >> >>this. >> >> > >> >> >Maybe when there are no +2's, simply take the sum of all votes, >> >> >and require it to be non-negative? >> >> >> >> That would work. Any other opinions? >> > >> >When there are no +2's *and -2's* ? >> >> I guess we are a little confused here. >> >> A -2 is a strong objection. So what we are saying is that with a strong >> objection we can't move forward. Now we are only using this scheme for >> expressing opinion informally and on Lazy Consensus. The central idea >> behind Lazy consensus is that WE DO NOT NEED to explicitly express >> agreement: in other words, the default when someone does not saying >> anything is a +1 (an implicit agreement). >> >> I added the "Only **-1** or **0** votes by all stake-holder whose", as >> this would be a strong signal that people generally think we don't have >>a >> good proposal and nobody is willing to defend it in any way. >> >> +2's and -2's are in some sense a way to highlight that we have a strong >> disagreement on an issue, whereas if we had +1's to -1's we only have a >> minor disagreement. >> >> I am not quite sure how to encode this using a formula. Looking for >> feedback, but will do a little research in Apache, Eclipse and other >>FOSS >> projects >> > >I wish we can't get into a situation that more than one rule could be >applied. So with your original words, a vote with one -2 and six +1's >(assuming 7 valid votes in total) can have two interpretations. Sorry for the late reply. Agreed. I wanted to end up with something simple for lazy consensus, which also takes into account that a non-reply states implicit consensus. We already have a more complex mechanism, in the section "Leadership Decisions", which makes decisions by 2/3 majority, which we can always fall back to. > Failed: A single **-2** by a stake-holder whose approval is necessary This would fit into the above set of requirements: simple and assumes that a non-reply states implicit consensus. > Passed: No +2's but total sum >0 I think the challenge is that there is a grey area. Also, I think that in general, we should only use "lazy consensus" where only a few people are involved (e.g. a 2-4 maintainers/committers in an area). Where everyone is affected, it seems to me that we should just follow the "Leadership Decisions" model. I think your Proposal may be simple enough: but I think there is a problem with Passed: No +2's but total sum >0 because it is probably fair to assume that the proposer of a proposal, will by default have at least a "+1" position. If the proposer is willing to argue for his/her proposal (which is likely), then the proposal could never pass. In any case, a single "+2" in absence of any "-2"'s should pass. How about The proposer of a lazy consensus is assumed to implicitly have an opinion of **+1**, unless otherwise stated. Passed: A total sum of opinions **>0** Failed: A single **-2** by a stake-holder whose approval is necessary Failed: A total sum of opinions **<=0** In case of failed lazy consensus, follow the pattern described in "Leadership Team Decisions" This would mean that a proposal would pass, if a proposal is made and no-one else expresses any opinion, which seems fair enough. In this case, the sum would be a "+1". It would also mean that it can't pass if there was a single -1 (as +1-1=0), unless - the proposer started out with a "+2" or - other people expressed a "+1" or "+2" in addition to the original proposer. Again, this seems fair enough. If a proposal was started with a "+2" by the proposer, a fellow maintainer could raise an objection by expressing a "-2", arguing that this specific proposal is too important to be left to lazy consensus and we would have to defer to the leadership team. In other words, we would discourage proposers to start out with a "+2" raising the bar for negative votes. This would also allow for some odd boundary cases, if a proposer started out with a **0** or **-1** to basically solicit opinions on something he/she is not 100% sure about or to verify that a way of doing something is probably not a good idea. Maybe the following background reading helps with terminology - http://oss-watch.ac.uk/resources/meritocraticgovernancevoting I think this does retain enough of lazy consensus, with some elements of lazy voting thrown in for the whole approach not to be too different to standard terminology. It does raise the question, whether we should call this la
