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, Lars Kurth wrote:
> On 01/12/2016 22:36, "Stefano Stabellini" <sstabellini@xxxxxxxxxx> 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
> >>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?
> 
> 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
> Vacation.
> 
> Is this workable?

+1 from me

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