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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

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 viewpoint:
> > 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?

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