On Aug 15, 2019, at 14:46, Lars Kurth <lars.kurth.xen@xxxxxxxxx> wrote:
On 15 Aug 2019, at 19:27, Rich Persaud <persaur@xxxxxxxxx> wrote:
On Aug 15, 2019, at 14:01, Lars Kurth <lars.kurth@xxxxxxxxxx> wrote:
Hi Rich,
thanks for the feedback. I am going to
On 15/08/2019, 18:23, "Rich Persaud" <persaur@xxxxxxxxx> wrote:
On Aug 9, 2019, at 13:48, Lars Kurth <lars.kurth@xxxxxxxxxx> 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 |
