On 01/12/2016 22:36, "Stefano Stabellini" <sstabell...@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
>> > 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
Is this workable?
Xen-api mailing list