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

[Lars Kurth <lars.kurth@xxxxxxxxxx>]

Hi Tim,

>At 00:13 +0100 on 12 Aug (1470960826), Lars Kurth wrote:
>> +### Conflict Resolution {#conflict}
>> +
>> +Sub-projects and teams hosted on Xenproject.org are not democracies
>>but 
>> +meritocracies. In situations where there is disagreement on issues
>>related to 
>> +the day-to-day running of the project, the [project leadership
>> +team](#leadership) is expected to act as referee and make a decision
>>on behalf 
>> +of the community. Projects leadership teams can choose to delegate
>>entire 
>> +classes of conflict resolution issues to community members and/or the
>>project 
>> +lead (e.g. the project can choose to delegate refereeing on committer
>> +disagreements to the project lead; or it could choose a specific
>>committer to 
>> +always act as referee amongst a group of committers). Any such
>>delegation needs 
>> +to be approved as normal and has to be documented.
>> +
>> +Should a project leadership team become dysfunctional or paralysed,
>>the project 
>> +leadership team or project lead should work with the community manager
>>or 
>> +advisory board to find a way forward.
>> +
>> +In situations where there is significant disagreement between
>>sub-projects, the
>> +issue is deferred to the [Xen Project Advisory Board](/join.html).
>
>This looks like a pretty significant shift of responsibilty to the AB.
>As I read it, the current governance requires a _vote_ if subprojects
>disagree, with the AB only called to break a tie.
>
>It also seems to conflict with the wording that the AB "leaves all
>technical decisions to the open source meritocracy".
>
>IMO if this is to be changed it should be to something more concrete
>than "significant disagreement".

That was not intentional. It crept in, because I wanted to avoid repeating
the phrase I used in the previous paragraph, purely for style reasons.

A bit of background on my thinking
A) The AB never felt comfortable with the tie-breaker scenario
B) The new voting model doesn't require the AB to be a tie maker any more
C) It does spell out the areas where AB sign-off is needed regardless of
   Community votes more clearly (in practice mostly it will primarily in
   areas where funds are needed to implement something)

   See your comment below

D) Also, from a scope perspective, global votes would only ever be about
   non-technical issues, such as policy

But I see your point. The text should really have said something like...
-----
In situations where the entire Xen Project community becomes paralysed,
the project leaderships team or project lead should work with the
community 
manager or advisory board to find a way forward.
-----


It would be nice to list an examples of "becoming paralysed", but
I can't think of anything.



>> +-   Some sections of this document such as [Xen Project wide
>> +roles](#roles-global) and [making contributions](#contributions)
>>**cannot be 
>> +changed by the community** without obtaining additional approval from
>>the 
>> +Advisory Board and/or the Linux Foundation, if these conflict
>>requirements that
>> +stem from being part of a Linux Foundation Collaborative Project (e.g
>>requiring 
>> +a contributor license agreement). Areas with such requirements cover
>> +trademarks, legal oversight, financial oversight and project funding.
>
>Again, this is a change from the current governance, which just
>delegates those things to the AB and leaves it at that (with the
>implication that the project as a whole controls its own governance).

I can see how this comes across. I will lay out my thoughts after answering
your other concerns.

>IMO it would be better to leave the AB wording as it is, and refer to
>a _specific_ LF policy document in the section on the LF.

I am lost now: there is not much wording related to the Advisory Board
in the original governance at all (except where the AB is defined). I
could 
take this entire paragraph out, as in fact we did not have it and we
Managed well. In practice, people would just come to me when there were
grey 
areas. 

>
>Or if people want a section like this then it should be a clear list
>of exactly which things require approval from which bodies, with no
>"such as" or similar, so there is no confusion later.

That's a problem, because there are no public documents listing these.
For example, there is no published document which says, collaborative
Projects must not have a CLA. But we were told that me must never
introduce one, when we became an LF project.

I put this section in, because in practice community members do tend
to come to me (as member of the AB) when it comes to funding stuff: e.g.
build and CI infra for the Win PV driver project, ... but these were
project local things. And we had past instances when an AB member
raised concrete issues (e.g. in 2012 a number of contributors were really
Unhappy that we didn't have a release and roadmap process). But in
hindsight, 
This paragraph doesn't add much and isn't really needed.

I think we have two options:
A) A delete this bullet entirely
B) Replace it with something clearer - even though, the location
for such a paragraph is wrong.

My gut feel is to just go for A.

Any objections?

Lars

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