Mailing List Archive

Re: [Xen-devel] [PATCH 3/3] Significant changes to decision making; some new roles and minor changes
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.

_______________________________________________
Xen-api mailing list
Xen-api@lists.xen.org
https://lists.xen.org/cgi-bin/mailman/listinfo/xen-api
Re: [Xen-devel] [PATCH 3/3] Significant changes to decision making; some new roles and minor changes [ In reply to ]
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

_______________________________________________
Xen-api mailing list
Xen-api@lists.xen.org
https://lists.xen.org/cgi-bin/mailman/listinfo/xen-api
Re: [Xen-devel] [PATCH 3/3] Significant changes to decision making; some new roles and minor changes [ In reply to ]
Hi,

At 14:55 +0000 on 15 Aug (1471272946), Lars Kurth wrote:
> 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.
> -----

Sure. I think that's good.

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

Sounds good to me.

Cheers,

Tim.

_______________________________________________
Xen-api mailing list
Xen-api@lists.xen.org
https://lists.xen.org/cgi-bin/mailman/listinfo/xen-api
Re: [Xen-devel] [PATCH 3/3] Significant changes to decision making; some new roles and minor changes [ In reply to ]
On 16/08/2016 06:32, "Tim Deegan" <tim@xen.org> wrote:

>Hi,
>
>At 14:55 +0000 on 15 Aug (1471272946), Lars Kurth wrote:
>> 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.
>> -----
>
>Sure. I think that's good.
>
>> 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.
>
>Sounds good to me.

Having looked at the text again (making edits for v2), I propose to add
the following
new section to the document.

-------------

- [Community Decisions with Funding and Legal
implications](#funding-and-legal)

...


Community Decisions with Funding and Legal Implications
(#funding-and-legal)
-------------------------------------------------------

In some cases sub-project local and global decisions **may require
input** from the [Advisory Board](#roles-ab) and/or the [Linux Foundation]
(#roles-lf). For example, if a proposal by a project leadership team or
a global project decision requires that the project hires a staff member
or
contractor (e.g. a PR consultant, marketing manager) or requires the
funding
of new infrastructure (e.g. additional test hardware or services) to
implement
said proposal, then funding would need to be secured from the Advisory
Board or
from other sources.

If for example, a community proposal required the Linux Foundation to sign
a legal agreement with a 3rd party on behalf of the project/sub-project,
then
of course a review of such an agreement and a signature by the Linux
Foundation
would be required.

In such cases, the impacted project leadership team(s) will contact the
Community Manager and/or Advisory Board to resolve possible issues.


-------------

I don't think this is in fact a change in governance. It is just clarifying


what has happened in the past. I merely wanted to highlight that in some
cases there are dependencies. We have not had any global changes, where
this
was the case, but we had a few local ones.

E.g.
- Windows driver signing required buying a cert and an agreement between
the
LF and Microsoft to deliver signed windows drivers
- The way how we make hypervisor releases requires to operate OSSTEST
(aka. COLO agreements, procurement of HW, technical support, ...) which
also required the LF to sign contracts on behalf of the project.

I hope that is OK

Best Regards
Lars

_______________________________________________
Xen-api mailing list
Xen-api@lists.xen.org
https://lists.xen.org/cgi-bin/mailman/listinfo/xen-api
Re: [Xen-devel] [PATCH 3/3] Significant changes to decision making; some new roles and minor changes [ In reply to ]
At 11:56 +0000 on 09 Sep (1473422177), Lars Kurth wrote:
> Community Decisions with Funding and Legal Implications
> (#funding-and-legal)
> -------------------------------------------------------
>
> In some cases sub-project local and global decisions **may require
> input** from the [Advisory Board](#roles-ab) and/or the [Linux Foundation]
> (#roles-lf). For example, if a proposal by a project leadership team or
> a global project decision requires that the project hires a staff member
> or
> contractor (e.g. a PR consultant, marketing manager) or requires the
> funding
> of new infrastructure (e.g. additional test hardware or services) to
> implement
> said proposal, then funding would need to be secured from the Advisory
> Board or
> from other sources.
>
> If for example, a community proposal required the Linux Foundation to sign
> a legal agreement with a 3rd party on behalf of the project/sub-project,
> then
> of course a review of such an agreement and a signature by the Linux
> Foundation
> would be required.
>
> In such cases, the impacted project leadership team(s) will contact the
> Community Manager and/or Advisory Board to resolve possible issues.
>
>
> -------------

FWIW, LGTM.

Cheers,

Tim.


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