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

[Ian Jackson <ian.jackson@xxxxxxxxxxxxx>]

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.

> 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.

This is a bad idea for the reason you say.  If someone gets two votes
in this way, so be it.

Ian.

_______________________________________________
Xen-api mailing list
Xen-api@xxxxxxxxxxxxx
https://lists.xen.org/cgi-bin/mailman/listinfo/xen-api