Re: [MirageOS-devel] [PATCH v5 3/3] Significant changes to decision making; some new roles and minor changes
Hello everybody!
I am Hussain, act as student.
I would like to ask few questions about Mirage Unikernel. In fact I built
Unikernel on Mirage because I have a project about ti.
1- How can I test booting speed of Unikernel.
2- After how many pings Unikernel is crash down.
My Regards
On Fri, Dec 2, 2016 at 10:06 PM, Stefano Stabellini
wrote:
> On Fri, 2 Dec 2016, Lars Kurth wrote:
> > On 01/12/2016 22:36, "Stefano Stabellini"
> 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.
> >
> > We could split out the following git repos: mini-os, osstest, raisin,
> > livepatch-build-tools, xtf
> > In terms of contributions per release, there is more activity than
> Windows
> > PV Drivers, which are a separate project.
>
> I see what you meant now. That could be OK.
>
> ___
> MirageOS-devel mailing list
> MirageOS-devel@lists.xenproject.org
> https://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
>
--
Hussain Fazul
Re: [MirageOS-devel] [PATCH v5 3/3] Significant changes to decision making; some new roles and minor changes
On Fri, 2 Dec 2016, Lars Kurth wrote:
> On 01/12/2016 22:36, "Stefano Stabellini" 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.
>
> We could split out the following git repos: mini-os, osstest, raisin,
> livepatch-build-tools, xtf
> In terms of contributions per release, there is more activity than Windows
> PV Drivers, which are a separate project.
I see what you meant now. That could be OK.
___
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
https://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
Re: [MirageOS-devel] [PATCH v5 3/3] Significant changes to decision making; some new roles and minor changes
On 01/12/2016 22:36, "Stefano Stabellini" 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.
We could split out the following git repos: mini-os, osstest, raisin,
livepatch-build-tools, xtf
In terms of contributions per release, there is more activity than Windows
PV Drivers, which are a separate project.
Lars
___
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
https://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
Re: [MirageOS-devel] [PATCH v5 3/3] Significant changes to decision making; some new roles and minor changes
On Thu, 1 Dec 2016, Lars Kurth wrote:
> On 01/12/2016 22:36, "Stefano Stabellini" 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@lists.xenproject.org
https://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
Re: [MirageOS-devel] [PATCH v5 3/3] Significant changes to decision making; some new roles and minor changes
On 01/12/2016 22:36, "Stefano Stabellini" 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?
Lars
___
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
https://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
Re: [MirageOS-devel] [PATCH v5 3/3] Significant changes to decision making; some new roles and minor changes
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@lists.xenproject.org
https://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
Re: [MirageOS-devel] [PATCH v5 3/3] Significant changes to decision making; some new roles and minor changes
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.
___
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
https://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
Re: [MirageOS-devel] [PATCH v5 3/3] Significant changes to decision making; some new roles and minor changes
On 01/12/2016 09:52, "Lars Kurth" wrote: >On 30/11/2016 23:27, "Stefano Stabellini" wrote: > >>On Wed, 23 Nov 2016, Lars Kurth wrote: >>> >>> >> >>This is basically the same voting mechanism described under "Leadership >>Team >>Decisions", counted per project, then averaged, isn't? > >That is correct. > >>It worries me that it could lead to very different results depending on >>the project leadership team sizes. >> >>For example, let's say that only 2 projects reach the quorum: >>project A, leadership team size 2, total positive votes 2, 100% >>project B, leadership team size 12, negative votes 8, positive votes 4, >>33% >>Total favor 66.5% -> pass (or very close to) > >The issue that prompted this change was in effect created by the number of >committers in different mature projects (aka, the fact that XAPI has 12 - >14 - I have to verify the correct number, as some people in the XAPI >committer list don't work on XAPI any more). Where according to the >current scheme, projects with large leadership teams can in effect use >their larger voting block to get their opinion through. > >One way of maybe addressing this, would be to be more specific about the >minimum size of a Leadership team (see "Projects without functional >Project Leadership Team"). I think a team needs to have at least 3 members >to be functional. Another way to add an extra check may be to add a >specific requirement to Graduation Review which checks that the Leadership >team is of an appropriate size for the size of the project (although we >may have to be specific on what an appropriate size is). > >In reality, we don't have a problem with this today, as the leadership >teams for the two mature projects (XAPI and Hypervisor) are actually >large. We have >* 7 for the Hypervisor >* 12 for XAPI (although this is probably to big, but in reality >participation tends to be low) > >The two projects which could qualify for maturity in the coming year are >Win PV drivers (3 leadership team members) and MirageOS (probably should >have a similar size to the Hypervisor Team). > >Also, it is worthwhile pointing out, that Global Decisions should >practically hardly ever be needed. Only in the following situations >1) Creating, graduating, completing/archiving of sub-projects >2) Some changes to this document (goals, principles, project wide decision >making and project governance): if we apply the new rules, only this >change would need a global decision (as we added a principle and changed >local decision making). And this would be the first one, we had since >introducing the governance 5 years ago >3) Namespace issues: aka naming conventions for lists, ... - which >primarily would be bike-shed issues. But again we only used this once >4) Boundary issues: aka making local per-subproject policies and >conventions global > >>However I don't have a concrete suggestion on how to improve this. Given >>that any project could appoint any number of people in their leadership >>teams, I am not sure that accounting for the size of the teams would >>make things much better. On the other hand the number of people in the >>leadership team should represent the size of the project somewhat, so it >>could make sense to account for the votes proportionally. >> >>Any opinions? > >The only other way I can think of is to weight a project's vote by some >level of activity (e.g. proportion of contributions averaged over 3 >years). But that would become complicated. > >Another way may be to add an extra bucket which contains all projects. In >the example above > >project A, leadership team size 2, total positive votes 2, 100% (pass) >project B, leadership team size 12, negative votes 8, positive votes 4, >33% (fail) >ALL (which is like the popular vote): size 14, negative votes 8, positive >votes 6, 42% (fail) >Average 58% (or very close to) -> fail ... which does change this example > > >Or some sort of rule, which requires that the popular and aggregated votes >have to be within a certain percentage of each other, otherwise the vote >does not count and has to be repeated I thought a bit more about this. Another way to look at it, which may be simpler, is to require that the "popular vote" A) Has a minimum requirement of 1/2 of the votes in favour. B) Or possibly better that there is a simple majority in the popular vote In this example, the total number of leadership team members across both teams is 14: the total number of votes in favour for the proposal is 6 and 8 against. So it would fail on a quorum requirement. Let's just look at this scenario in different ways: aka make it closer A: 2/2 in favour (100%) pass B: 5/12 in favour (41.666%) fail ALL: 7/14 in favour (50%) pass quorum, but no majority, fail 2/3 vote Average (A+B) = 70.8% pass, pass on quorum Average (A+B+ALL) = 63.888% (fail on 2/3 vote) I didn't look at the maths, but it looks to me that Average (A+B+ALL) would be quite similar to requiring that ALL also has a simple majority. Maybe
Re: [MirageOS-devel] [PATCH v5 3/3] Significant changes to decision making; some new roles and minor changes
On 30/11/2016 23:27, "Stefano Stabellini" wrote:
>On Wed, 23 Nov 2016, Lars Kurth wrote:
>>
>> -Formal Votes {#formal-votes}
>> -
>> -
>> -Sometimes it is necessary to conduct formal voting within the
>>community
>> -(outside of elections). Formal votes are necessary when processes and
>> -procedures are introduced or changed, or as part of the [Project
>> -Governance](#project-governance). Who is eligible to vote, depends on
>>whether
>> -the scope of a process or procedure is **local** to a sub-project or
>>team, or
>> -whether it affects **all sub-projects** (or in other words, is
>>**global**).
>> -Examples of local scope is the [Security
>>Policy](/security-policy.html) which
>> -applies to the [Hypervisor Project](/developers/teams/hypervisor.html)
>>only.
>> -Examples of global scope are changes to this document or votes
>>outlined in the
>> -Project Governance.
>> -
>> -
>>-
>>
>> - **Scope****Who reviews?** **Who votes?**
>> - --
>>-
>> - **Local**Members of developer Maintainers of the project (or
>>projects),
>> - mailing lists of the which are affected by the
>>process,
>> - affected projects. procedure, etc. are allowed to
>>vote.
>> - This includes maintainers from
>>incubation
>> - projects (if the scope affects
>>the
>> - project).
>> -
>> - **Global** Members of all Maintainers of **all mature**
>>projects
>> - developer mailing and the Xenproject.org community
>>manager
>> - lists of all are allowed to vote.
>> - sub-projects hosted on
>> - Xenproject.org.
>> -
>>-
>>
>> -\
>> +Projects which have a project lead, should vote for a project lead in
>>an
>> +anonymous vote amongst the project leadership.
>> +
>> +### Project Wide Decision Making {#project-decisions}
>> +
>> +Project wide decisions are made through **formal global votes** and
>>are
>> +conducted in rare circumstances only, following the principle of
>>[local
>> +decision making](#principles). Global votes are only needed, when all
>>sub-projects
>> +hosted on Xenproject.org are affected. This is true, only for:
>> +
>> +- Specific votes on creating, graduating, completing/archiving of
>> +sub-projects as outlined in [project governance](#project-governance).
>> +- Changes to this document, where sub-projects cannot specialise. In
>> +particular the sections: [goals](#goals), [principles](#principles),
>>[project
>> +wide decision making](#project-decisions) and [project
>> +governance](#project-governance) (and small parts of [Xen Project wide
>> +roles](#roles-global), [project team roles](#roles-local) and
>>[decision
>> +making](#decisions) that are needed for project governance or **apply
>>to all
>> +sub-projects** as stated in those sections).
>> +- Changes to this document where sub-projects can specialise require
>>at least
>> +one mature project other than the Hypervisor project to be impacted
>> +significantly by the change. The sections in question, are [project
>>team
>> +roles](#roles-local) and [decision making](#decisions). These sections
>>define
>> +the **gold standard** of how the original Hypervisor Project operates.
>>In other
>> +cases, the Hypervisor project leadership team can agree changes to
>>these
>> +sections, as they are essentially reference definitions. Other
>>sub-projects
>> +have to be consulted, and have to be given time to adapt to changes.
>> +- Changes to existing global namespace policies (e.g. [Mailing List
>>
>>+Conventions](/help/mailing-list/100-misc/139-mailing-list-conventions.ht
>>ml))
>> +and creation of new project wide namespace policies.
>> +- Changes to the boundary of what policies are project local and
>>global
>> +decision: e.g. a decision to introduce a global Security Vulnerability
>>Response
>> +Process that affects all sub-projects.
>> +
>> +Global votes are arranged by the community manager when needed (e.g.
>>for a
>> +project review or a global process change). Who exactly has input on a
>>proposal
>> +and can vote on it, depends on the type of change as outlined below:
>> +
>> +
>>-
>>
>> + **Proposal** **Who reviews?** **Who
>>votes?**
>> + - -
>>-
>> + Creating, graduating, Members of developer mailing
>>Leadership teams of
>> + completing/archiving of lists of qualifying projects
>>**mature** sub-projects,
>> + sub-project
Re: [MirageOS-devel] [PATCH v5 3/3] Significant changes to decision making; some new roles and minor changes
On Wed, 23 Nov 2016, Lars Kurth wrote:
> List of changes
> - Added Goal: Local Decision Making
> - Split roles into project wide and sub-project specific roles
> - Added new roles: Community Manager, Security Response Team, Leadership Team
> - Added RTC Policy
> - Added +2 ... -2 scheme for expressing opinions more clearly
> - Clarified lazy consensus / lazy voting with examples
> - Added Informal Votes or Surveys
> - Added Project Team Leadership decisions (majority vote, non-monotonicity)
> - Clarified and Adapted Conflict Resolution to previous changes
> - Updated Elections to cover new roles and terminology
> - Changed Project Wide Decision making (per project, non-monotonicity)
> - Clarified scope of Decision making
> - Added section on Community Decisions with Funding and Legal Implications
> - Modified all other sections which have dependencies on changes above
> - Added Per Sub-Project Governance Specialisation
> - Fixed various typos
> - Fixed changelog
>
> Signed-off-by: Lars Kurth
> ---
> governance.pandoc | 628
> ++
> 1 file changed, 496 insertions(+), 132 deletions(-)
>
> diff --git a/governance.pandoc b/governance.pandoc
> index 2ce780c..188fa41 100644
> --- a/governance.pandoc
> +++ b/governance.pandoc
> @@ -1,5 +1,5 @@
> This document has come in effect in June 2011 and will be reviewed
> periodically
> -(see revision sections). The last modification has been made in July 2016.
> +(see revision sections). The last modification has been made in December
> 2016.
>
> Content
> ---
> @@ -11,8 +11,10 @@ Content
> - [Making Contributions](#contributions)
> - [Decision Making, Conflict Resolution, Role Nominations and
> Elections](#decisions)
> -- [Formal Votes](#formal-votes)
> +- [Project Wide Decision Making](#project-decisions)
> +- [Community Decisions with Funding and Legal
> Implications](#funding-and-legal)
> - [Project Governance](#project-governance)
> +- [Per Sub-Project Governance Specialisations](#specialisations)
>
> Goals {#goals}
> -
> @@ -54,7 +56,12 @@ The Xen Project is a meritocracy. The more you contribute
> the more
> responsibility you will earn. Leadership roles in Xen are also merit-based
> and
> earned by peer acclaim.
>
> -Xen Project Wide Roles {#roles-global}
> +### Local Decision Making
> +
> +The Xen Project consists of a number of sub-projects: each sub-project makes
> +technical and other decisions that solely affect it locally.
> +
> +Xen Project Wide Roles {#roles-global}
> --
>
> ### Sub-projects and Teams
> @@ -64,9 +71,22 @@ the [Project Governance](#project-governance) (or Project
> Lifecycle) as
> outlined in this document. Sub-projects (sometimes simply referred to as
> projects) are run by individuals and are often referred to as teams to
> highlight the collaborative nature of development. For example, each
> -sub-project has a [team portal](/developers/teams.html) on Xenproject.org.
> +sub-project has a [team portal](/developers/teams.html) on Xenproject.org.
> +Sub-projects own and are responsible for a collection of source repositories
> +and other resources (e.g. test infrastructure, CI infrastructure, ...),
> which
> +we call **sub-project assets** (or team assets) in this document.
> +
> +Sub-projects can either be **incubation projects** or **mature projects** as
> +outlined in [Basic Project Life Cycle](#project-governance). In line with
> the
> +meritocratic principle, mature projects have more influence than incubation
> +projects, on [project wide decisions](#project-decisions).
> +
> +### Community Manager
>
> -### Xen Project Advisory Board
> +The Xen Project has a community manager, whose primary role it is to support
> +the entire Xen Project Community.
> +
> +### Xen Project Advisory Board {#roles-ab}
>
> The [Xen Project Advisory Board](/join.html) consists of members who are
> committed to steering the project to advance its market and technical
> success,
> @@ -76,7 +96,7 @@ shared project infrastructure, marketing and events, and
> managing the Xen
> Project trademark. The Advisory Board leaves all technical decisions to the
> open source meritocracy.
>
> -### The Linux Foundation
> +### The Linux Foundation {#roles-lf}
>
> The Xen Project is a [Linux Foundation](/linux-foundation.html)
> Collaborative
> Project. Collaborative Projects are independently funded software projects
> that
> @@ -95,21 +115,48 @@ members or other distinguished community members.
> ### Sponsor
>
> To form a new sub-project or team on Xenproject.org, we require a sponsor to
> -support the creation of the new project. A sponsor can be a project lead or
> -committer of a mature project, a member of the advisory board or the
> community
> -manager. This ensures that a distinguished community member supports the
> idea
> -behind the project.
> +support the creation of the new project. A
