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.
I think at this stage I would like to hear the opinions of others, as there was quite a bit of discussion that led us to where we are and some people looked into this aside from me
I think all of your concerns can be addressed either way by modifying the proposal or modifying the covenant
Are there upstream examples of electoral governance for "CoC teams", or would we need to develop that from scratch?
We don't need to invent anything, we can use our standard election process if we need too. It's designed to be applicable for all kind of roles in the community 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?
I was actually thinking that the CoC team would be made up of members of * Xen project leadership from different sub-projects (not just the Hypervisor committers). Rationale: the CoC is project wide, not specific to xen-devel@ And we have some leadership team members which do not want to have to deal with CoC issues * Advisory Board members (if one wanted to volunteer) * Optionally we could use the normal election process to elect someone who is not a leadership team member. Rationale: diversity - it would be nice to have a women on the team such that we don't get blind sighted should an issue occur. But we don't currently have female leadership team members. Mirage OS is an exception, but Mirage OS does not fully follow our conventions in electing leadership team members
In any case: I think I need to hear more different views
Lars
|
