> On Aug 15, 2019, at 14:46, Lars Kurth <lars.kurth....@gmail.com> wrote:
>> On 15 Aug 2019, at 19:27, Rich Persaud <pers...@gmail.com> wrote:
>> On Aug 15, 2019, at 14:01, Lars Kurth <lars.ku...@citrix.com> wrote:
>>
>>> Hi Rich,
>>>
>>> thanks for the feedback. I am going to
>>>
>>> On 15/08/2019, 18:23, "Rich Persaud" <pers...@gmail.com> wrote:
>>>
>>>> On Aug 9, 2019, at 13:48, Lars Kurth <lars.ku...@citrix.com> wrote:
>>>>
>>>> Hi all,
>>>
>>> Hi Lars,
>>>
>>>>
>>>> Following the discussion we had at the Developer Summit (see
>>>> https://wiki.xenproject.org/wiki/Design_Sessions_2019#Community_Issues_.2F_Improvements_-_Communication.2C_Code_of_Conduct.2C_etc.
>>>> for notes) I put together a draft for the Code of Conduct which can be
>>>> found here as well as inlined below
>>>> https://docs.google.com/document/d/1NnWdU_VnC1N_ZzxQG6jU9fnY2GPVCcfPJT5KY61WXJM/edit?usp=sharing
>>>>
>>>> It is based on the LF Events CoC as we agreed on (the diff is attached). I
>>>> took the scope and enforcement sections from
>>>> https://www.contributor-covenant.org/version/1/4/code-of-conduct.html and
>>>> simplified it rather than inventing something new.
>>>
>>> Is there precedent for applying a legal contract (Code of Conduct) that
>>> was designed for physical space (conference event) to an online context?
>>> Is there an existing Code of Conduct that was legally designed for a
>>> similar, online open-source community context, e.g. operating system or
>>> hypervisor or other systems-level software dev?
>>>
>>> If you look at
>>> https://www.contributor-covenant.org/version/1/4/code-of-conduct.html or
>>> many other examples, what we ended up with is almost identical. The same is
>>> true for most other CoCs which are used as “gold standard”.
>>
>> Thanks for the pointer, that's exactly what I was hoping to find. Here is
>> some text from Contributor Covenant:
>>
>> "Instances of abusive, harassing, or otherwise unacceptable behavior may be
>> reported by contacting the project team at [INSERT EMAIL ADDRESS]. All
>> complaints will be reviewed and investigated and will result in a response
>> that is deemed necessary and appropriate to the circumstances. The project
>> team is obligated to maintain confidentiality with regard to the reporter of
>> an incident. Further details of specific enforcement policies may be posted
>> separately.
>> Project maintainers who do not follow or enforce the Code of Conduct in good
>> faith may face temporary or permanent repercussions as determined by other
>> members of the project’s leadership."
>>
>> This is different from the proposed CoC, because:
>>
>> (a) repercussions are not specified, i.e. they can be contextual
>> (b) there is a confidentiality provision
>> (c) decisions are made by open-source project leadership, not a separate
>> "CoC team" with TBD members, electoral process and governance
>>
>> Can Xen Project adopt Contributor Covenant directly? It has a large base of
>> adopters, including Intel and Google projects, so we would benefit from
>> upstream improvements as the CoC is tested in the real world:
>> https://www.contributor-covenant.org/adopters
>
> We most definitely could and I am open to the idea. However, when Linux
> adopted it, there was significant controversy because of the origin of the
> Contributor Covenant
>
> See https://itsfoss.com/linux-code-of-conduct/
>
> I am not sure what the risk would be if we followed Linux
>
> However, we can address all of the above with what we have: The section you
> quoted was indeed from the covenant (see attribution) and I simply modified
> it based on the discussion we had at the summit.
>
>
> a) We could leave the repercussion section out - I think it is clearer to
> have one, but we can clearly debate the pros and cons of not having one
> b) There is a confidentiality provision: "The Xen Project’s CoC team is
> obligated to maintain confidentiality with regard to the reporter of an
> incident."
> c) In the design session at the summit the present project leadership team
> members felt we should have a CoC team, which is why I changed it
>
> In any case, the Covenant suggested to customise the template to our needs.
> And that's what I have done.
>
> It was also interesting that when I started with the LF events CoC, I still
> ended up with something very similar to most of the other CoCs out there
Differences remain, e.g. Contributor Covenant has a whitelist and blacklist of
acceptable behaviors, the proposed Xen CoC only has a blacklist. Although you
say the CoC is not a legal document, the proposed Xen statement of acceptable
behaviors does mention "applicable laws", which is absent from Contributor
Covenant.
Without getting into the merits of Contributor Covenant, there is value in
reusing an "upstream CoC" that has been vetted by many organizations and is
being continually tested in the real world.
Similar to the "macro supply chain" topic: if Xen Project must make changes to
the upstream CoC, these can be done as a logical patch (rather than an orphaned
fork) so we can incorporate upstream improvements. The rationale for each diff
against the upstream CoC can be in a revision-controlled doc, so that future
CoC maintainers understand the reasoning behind each diff, as communities and
contributors evolve.
Are there upstream examples of electoral governance for "CoC teams", or would
we need to develop that from scratch? Xen Summit design session notes say:
"An area for discussion which was not quite agreed upon pending an initial
proposal was how we would approach the handling of issues
A committee
Probably 2-3 people of different backgrounds maybe from different subprojects"
Could we also include existing Xen project leadership in the CoC team? How
would selection of people for a CoC team differ from the existing process for
selecting committers, etc?
Rich
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
