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

[Tim Deegan <tim@xxxxxxx>]

Hi,

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

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

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.

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.

Cheers,

Tim.

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