Xen project Mailing List

From: Rich Persaud <persaur@xxxxxxxxx>
Date: Friday, 16 August 2019 at 16:49
To: George Dunlap <George.Dunlap@xxxxxxxxxx>
Cc: Lars Kurth <lars.kurth@xxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, "minios-devel@xxxxxxxxxxxxxxxxxxxx" <minios-devel@xxxxxxxxxxxxxxxxxxxx>, "mirageos-devel@xxxxxxxxxxxxxxxxxxxx" <mirageos-devel@xxxxxxxxxxxxxxxxxxxx>, "win-pv-devel@xxxxxxxxxxxxxxxxxxxx" <win-pv-devel@xxxxxxxxxxxxxxxxxxxx>, "committers@xxxxxxxxxxxxxx" <committers@xxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [RFC] Code of Conduct

Snip

Hi George,

Thanks for the detailed response. Lars noted that the proposed Xen CoC is nearly identical to Contributor Covenant, which has been adopted by many organizations, including teams at Intel and Google. My comment, from https://lists.gt.net/xen/devel/561686#561686

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.

Your discussion above clearly covers differences between Contributor Covenant and Xen's CoC, and could be translated to text suitable for commit messages, with one commit per diff from an upstream CoC.

Rich

This is not really productive. I was looking for concrete feedback, but we ended up with a long discussion with no actionable items that can help resolve the discussion.

How about the following:

· Make a proposal based on the Contributor Covenant

· Try and address some of the key customizations which I have been trying to make (which George outlined nicely)

This shouldn’t take much longer than the time you, George and I spent on this email thread already. You can follow the methodology you propose

We can then compare the output and decide which one to go for

Lars

Thank you for the chat at Security Summit. So, I think we concluded that the direction we are going in is roughly correct.

In the meantime, I had talked to the LF. There is currently an initiative to provide the following

General advice on how to choose and customize CoCs – almost certainly Contributor Covenant will be on that list
A template and set of best practices on how to implement enforcement + training around it

I did raise the issue of a cross-project support network, which has not yet been on the agenda. I will be hooked into this process.
My gut feeling is that we are looking at 6-9 months before all of this is resolved. Maybe longer.

Ultimately, we have 3 options:

We wait for the LF and revisit then
We go our own way re customization
We draft our own customizations and bring it up in one of the LF meetings discussing this

My gut feeling is to go for c) and I am willing to have a try at customizing the Contributor Covenant along the lines of the previous exercise

What do people think?

Regards

Lars