On Thu, 1 Dec 2016, Lars Kurth wrote: > 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 > >>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 _______________________________________________ Xen-devel mailing list Xenfirstname.lastname@example.org https://lists.xen.org/xen-devel