Re: [MirageOS-devel] [PATCH v5 3/3] Significant changes to decision making; some new roles and minor changes

[Lars Kurth <lars.kurth@xxxxxxxxxx>]

On 01/12/2016 09:52, "Lars Kurth" <lars.kurth@xxxxxxxxxx> wrote:

>On 30/11/2016 23:27, "Stefano Stabellini" <sstabellini@xxxxxxxxxx> 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

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel