[Xen-devel] [RFC] Code of Conduct

[Xen-devel] [RFC] Code of Conduct

[Lars Kurth]

[-- Attachment #1: Type: text/plain, Size: 4772 bytes --]

Hi all,

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.

You can provide feedback by commenting on the google doc or by replying to the in-lined version below. 
I expect it will some more discussion to get consensus. 

Note that I am not very attached to some of the terms, such as "Xen Project CoC  Team" and in some cases "participant" should probably be replaced by community 
members. 

But I felt, we should have something more concrete to discuss compared to previous discussions.

A Code of Conduct is a project wide policy change: thus, all subprojects lists are CC'ed

Regards
Lars

Here is the actual text
---
# Our Pledge
In the interest of fostering an open and welcoming environment, we as community 
members of the Xen Project pledge to making participation in our project and our 
community a harassment-free experience for everyone.

We believe that a Code of Conduct can help create a harassment-free environment, 
but is not sufficient to create a welcoming environment on its own: guidance on creating 
a welcoming environment, how to communicate in an effective and friendly way, etc. 
can be found <here>.

# Scope
This Code of Conduct applies within all Xen Project project spaces, and it also applies 
when an individual is representing the Xen Project or its community in public spaces. 
Examples of representing the Xen Project include using an official project email address, 
posting via an official social media account, or acting as an appointed representative 
at an online or offline event. 

# Expected Behavior
All Xen Project community members are expected to behave in accordance with 
professional standards, with both the Xen Project Code of Conduct as well as their 
respective employer’s policies governing appropriate workplace behavior, and 
applicable laws.

# Unacceptable Behavior
Harassment will not be tolerated in the Xen Project Community in any form, 
including but not limited to harassment based on gender, gender identity and 
expression, sexual orientation, disability, physical appearance, body size, race, 
age, religion, ethnicity, nationality, level of experience, education, or 
socio-economic status or any other status protected by laws in jurisdictions in 
which community members are based. Harassment includes the use of abusive, 
offensive or degrading language, intimidation, stalking, harassing photography 
or recording, inappropriate physical contact, sexual imagery and unwelcome 
sexual advances, requests for sexual favors, publishing others' private 
information such as a physical or electronic address without explicit permission 
and other conduct which could reasonably be considered inappropriate in a 
professional setting. 

Any report of harassment within the Xen Project community will be addressed 
swiftly. Participants asked to stop any harassing behavior are expected to 
comply immediately. Anyone who witnesses or is subjected to unacceptable 
behavior should notify the Xen Project’s CoC team via conduct@xenproject.org.

# Consequences of Unacceptable Behavior
If a participant engages in harassing behavior, the Xen Project’s CoC team may 
take any action it deems appropriate, ranging from issuance of a warning to the 
offending individual to expulsion from the Xen Project community.

# What To Do If You Witness Or Are Subject To Unacceptable Behavior
Instances of abusive, harassing, or otherwise unacceptable behavior may be
reported by contacting the Xen Project’s CoC team at conduct@xenproject.org. 
All complaints will be reviewed and investigated and will result in a response 
that is deemed necessary and appropriate to the circumstances. The Xen Project’s 
CoC team is obligated to maintain confidentiality with regard to the reporter of an 
incident.

# Attribution
This Code of Conduct is based on the Linux Foundation Events Code of Conduct 
(see https://events.linuxfoundation.org/code-of-conduct/). The Scope and What 
To Do If You Witness Or Are Subject To Unacceptable Behavior sections of this 
code of conduct have been adapted from the Contributor Covenant v1.4.
---


[-- Attachment #2: Xen CoC (diff against baseline).pdf --]
[-- Type: application/pdf, Size: 70783 bytes --]

[-- Attachment #3: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RFC] Code of Conduct

[Rich Persaud]

> On Aug 9, 2019, at 13:48, Lars Kurth <lars.kurth@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?


> You can provide feedback by commenting on the google doc or by replying to the in-lined version below. 
> I expect it will some more discussion to get consensus. 
> 
> Note that I am not very attached to some of the terms, such as "Xen Project CoC  Team" and in some cases "participant" should probably be replaced by community 
> members. 
> 
> But I felt, we should have something more concrete to discuss compared to previous discussions.
> 
> A Code of Conduct is a project wide policy change: thus, all subprojects lists are CC'ed
> 
> Regards
> Lars
> 
> Here is the actual text
> ---
> # Our Pledge
> In the interest of fostering an open and welcoming environment, we as community 
> members of the Xen Project pledge to making participation in our project and our 
> community a harassment-free experience for everyone.
> 
> We believe that a Code of Conduct can help create a harassment-free environment, 
> but is not sufficient to create a welcoming environment on its own: guidance on creating 
> a welcoming environment, how to communicate in an effective and friendly way, etc. 
> can be found <here>.
> 
> # Scope
> This Code of Conduct applies within all Xen Project project spaces, and it also applies 
> when an individual is representing the Xen Project or its community in public spaces. 
> Examples of representing the Xen Project include using an official project email address, 
> posting via an official social media account, or acting as an appointed representative 
> at an online or offline event. 
> 
> # Expected Behavior
> All Xen Project community members are expected to behave in accordance with 
> professional standards, with both the Xen Project Code of Conduct as well as their 
> respective employer’s policies governing appropriate workplace behavior, and 
> applicable laws.

In the x86 community call where this was first discussed, I suggested that we try to define desirable behavior, which we would like to incentivize and promote.   In this current draft, we have a single sentence on positive behavior, with inclusion-by-reference to:

- professional standards
- corporate policy
- city, state and national/federal law

If it is sufficient to define acceptable behavior by reference to external governance institutions and cultural practices, can we do the same for unacceptable behavior, i.e. anything that violates the above?

If incorporation-by-reference is not sufficient, e.g. if we will maintain a blacklist of unacceptable behavior for collaborative, online open-source development, do we also need a whitelist of acceptable behavior?  Within Xen source code, we have been moving away from blacklists towards whitelists.


> # Unacceptable Behavior
> Harassment will not be tolerated in the Xen Project Community in any form, 
> including but not limited to harassment based on gender, gender identity and 
> expression, sexual orientation, disability, physical appearance, body size, race, 
> age, religion, ethnicity, nationality, level of experience, education, or 
> socio-economic status or any other status protected by laws in jurisdictions in 
> which community members are based. Harassment includes the use of abusive, 
> offensive or degrading language, intimidation, stalking, harassing photography 
> or recording, inappropriate physical contact, sexual imagery and unwelcome 
> sexual advances, requests for sexual favors, publishing others' private 
> information such as a physical or electronic address without explicit permission

Picking one item at random:  would a conference-originated blacklist prohibition be appropriate for online open-source development?  E.g. if someone's email address were included in a xen-devel thread (on the cc line), without obtaining explicit permission, would that be unacceptable behavior for a Xen developer?  That could disqualify much of the current development community.


> Any report of harassment within the Xen Project community will be addressed 
> swiftly. Participants asked to stop any harassing behavior are expected to 
> comply immediately. Anyone who witnesses or is subjected to unacceptable 
> behavior should notify the Xen Project’s CoC team via conduct@xenproject.org.
> 
> # Consequences of Unacceptable Behavior
> If a participant engages in harassing behavior, the Xen Project’s CoC team may 
> take any action it deems appropriate, ranging from issuance of a warning to the 
> offending individual to expulsion from the Xen Project community.

This is an enforceable action in the physical world, e.g. conference event, but may be more difficult online.  As the existence of spam, bots, robocallers and cyberattack attribution forensics have shown, digital identity is not as clear cut as physical identity at a conference.   It may be better to look for precedent CoC legal clauses that were designed for online contexts.

Let's assume that digital identity can be proven and a person can be expelled from the Xen Project community.  Would this action apply only to the person's digital identity at Company X, or also to their new digital identity at Company Y?  i.e. would behavior and enforcement be scoped to the individual, the company or both?  

The "Acceptable Behavior" clause includes individual, company and nation-state in scope of governance.  If the "Unacceptable Behavior" clauses would lead to economic harm for a company, e.g. impacting a company's ability to ship a commercial release of  product with Xen Project components, would the company be given an opportunity to improve the behavior of their employee, within the employment context of their work in the collaborative, open-source development of Xen?  What would be due process for such improvement opportunity, in compliance with nation-state labor laws for employee termination?

If the "Unacceptable Behavior" clauses would lead to blacklisting of a person's digital and physical identities from the online, collaborative, open-source development community of Xen, would this have a material impact on the ability of that human to find employment in any company or nation-state?  If so, would such a public employment blacklist be compliant with the labor laws of affected nation-states?  

Would Xen-contributing companies be required to enforce the blacklist when hiring employees?  If so, would this create the appearance of a "cartel", a construct prohibited by some nation-states under antitrust law.  If not, would there be dis-incentives for a Xen-contributing company to hire someone who could not participate in the online, collaborative, open-source development community for Xen Project?

Would these considerations influence a company which is selecting a global labor pool of hypervisor talent and open-source hypervisor for their commercial product?  Can we perform a comparative analysis of these scenarios for the proposed Xen Project CoC vs. other OSS hypervisors which compete with Xen?

These are some example scenarios where a conference/event CoC may not be suitable.

Rich
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RFC] Code of Conduct

[Lars Kurth]

[-- Attachment #1.1: Type: text/plain, Size: 9606 bytes --]

Hi Rich,



thanks for the feedback. I am going to



On 15/08/2019, 18:23, "Rich Persaud" <persaur@gmail.com> wrote:



    > On Aug 9, 2019, at 13:48, Lars Kurth <lars.kurth@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”.

Also of course, the Code of Conduct is not a legal or legally enforceable document



    > # Expected Behavior

    > All Xen Project community members are expected to behave in accordance with

    > professional standards, with both the Xen Project Code of Conduct as well as their

    > respective employer’s policies governing appropriate workplace behavior, and

    > applicable laws.



    In the x86 community call where this was first discussed, I suggested that we try to define desirable behavior, which we would like to incentivize and promote.   In this current draft, we have a single sentence on positive behavior, with inclusion-by-reference to:



    - professional standards

    - corporate policy

    - city, state and national/federal law



    If it is sufficient to define acceptable behavior by reference to external governance institutions and cultural practices, can we do the same for unacceptable behavior, i.e. anything that violates the above?



    If incorporation-by-reference is not sufficient, e.g. if we will maintain a blacklist of unacceptable behavior for collaborative, online open-source development, do we also need a whitelist of acceptable behavior?  Within Xen source code, we have been moving away from blacklists towards whitelists.


I think we agreed all to look at desirable behaviour, but cover this elsewhere. This is what is covered in the “Our Pledge” section at the end. I just have not gotten round to write this yet as it is a lot more complex. When this was discussed, I thought we decided to keep the desirable behaviour out of the CoC as otherwise people may get the impression that if they come across as for example unfriendly, there may be consequences.



    > # Unacceptable Behavior

    > Harassment will not be tolerated in the Xen Project Community in any form,

    > including but not limited to harassment based on gender, gender identity and

    > expression, sexual orientation, disability, physical appearance, body size, race,

    > age, religion, ethnicity, nationality, level of experience, education, or

    > socio-economic status or any other status protected by laws in jurisdictions in

    > which community members are based. Harassment includes the use of abusive,

    > offensive or degrading language, intimidation, stalking, harassing photography

    > or recording, inappropriate physical contact, sexual imagery and unwelcome

    > sexual advances, requests for sexual favors, publishing others' private

    > information such as a physical or electronic address without explicit permission



    Picking one item at random:  would a conference-originated blacklist prohibition be appropriate for online open-source development?  E.g. if someone's email address were included in a xen-devel thread (on the cc line), without obtaining explicit permission, would that be unacceptable behavior for a Xen developer?  That could disqualify much of the current development community.



Again, the list is very similar to those in most other CoC’s. So, I think the answer is yes



    > Any report of harassment within the Xen Project community will be addressed

    > swiftly. Participants asked to stop any harassing behavior are expected to

    > comply immediately. Anyone who witnesses or is subjected to unacceptable

    > behavior should notify the Xen Project’s CoC team via conduct@xenproject.org.

    >

    > # Consequences of Unacceptable Behavior

    > If a participant engages in harassing behavior, the Xen Project’s CoC team may

    > take any action it deems appropriate, ranging from issuance of a warning to the

    > offending individual to expulsion from the Xen Project community.



    This is an enforceable action in the physical world, e.g. conference event, but may be more difficult online.  As the existence of spam, bots, robocallers and cyberattack attribution forensics have shown, digital identity is not as clear cut as physical identity at a conference.   It may be better to look for precedent CoC legal clauses that were designed for online contexts.



    Let's assume that digital identity can be proven and a person can be expelled from the Xen Project community.  Would this action apply only to the person's digital identity at Company X, or also to their new digital identity at Company Y?  i.e. would behavior and enforcement be scoped to the individual, the company or both?



    The "Acceptable Behavior" clause includes individual, company and nation-state in scope of governance.  If the "Unacceptable Behavior" clauses would lead to economic harm for a company, e.g. impacting a company's ability to ship a commercial release of  product with Xen Project components, would the company be given an opportunity to improve the behavior of their employee, within the employment context of their work in the collaborative, open-source development of Xen?  What would be due process for such improvement opportunity, in compliance with nation-state labor laws for employee termination?



    If the "Unacceptable Behavior" clauses would lead to blacklisting of a person's digital and physical identities from the online, collaborative, open-source development community of Xen, would this have a material impact on the ability of that human to find employment in any company or nation-state?  If so, would such a public employment blacklist be compliant with the labor laws of affected nation-states?



    Would Xen-contributing companies be required to enforce the blacklist when hiring employees?  If so, would this create the appearance of a "cartel", a construct prohibited by some nation-states under antitrust law.  If not, would there be dis-incentives for a Xen-contributing company to hire someone who could not participate in the online, collaborative, open-source development community for Xen Project?



    Would these considerations influence a company which is selecting a global labor pool of hypervisor talent and open-source hypervisor for their commercial product?  Can we perform a comparative analysis of these scenarios for the proposed Xen Project CoC vs. other OSS hypervisors which compete with Xen?



    These are some example scenarios where a conference/event CoC may not be suitable.



In a nutshell: if for example I performed a series CoC violation that could lead me losing my job. For example, if I were to send sexually explicit material to another community member and that person reports it, and our CoC team verifies that indeed the material was sent from my laptop, I would expect that I could be expelled as community member.  However, in this case (and probably most cases) that I would also violate my employer’s policies governing appropriate workplace and could lose my job if the victim reported the issue to my employer.



The challenge for the project would be to communicate why a community member was expelled. In such a scenario:

  1.  If we stay opaque there may be community pushback
  2.  If we are transparent about the reasons that may lead to severe consequences for the person who committed a series CoC violation – primarily because of the public nature of the communication about the CoC violation


In any case, the fact that the text was based on an events CoC is in my view irrelevant, because the issues you outlined apply to every CoC out there. They are intrinsic to having a CoC.



There are very few examples of how projects would indeed handle violations. A good example is Django: see
* https://www.djangoproject.com/conduct/enforcement-manual/
* https://www.djangoproject.com/conduct/reporting/

I won’t be able to spend much time on this in the next two weeks, but I wanted to make my position clear, before we end up in a long discussion on detail which I think is not relevant to the specific text but to the fact that we introduce a CoC.

Best Regards
Lars











[-- Attachment #1.2: Type: text/html, Size: 21120 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RFC] Code of Conduct

[Rich Persaud]

[-- Attachment #1.1: Type: text/plain, Size: 2966 bytes --]

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

Rich

[-- Attachment #1.2: Type: text/html, Size: 8629 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [win-pv-devel] [RFC] Code of Conduct

[Lars Kurth]

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

Lars



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [win-pv-devel] [RFC] Code of Conduct

[Rich Persaud]

[-- Attachment #1.1: Type: text/plain, Size: 5879 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 12985 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RFC] Code of Conduct

[Lars Kurth]

[-- Attachment #1.1: Type: text/plain, Size: 7319 bytes --]



> On 15 Aug 2019, at 20:08, Rich Persaud <persaur@gmail.com> wrote:
>>>>> 
>>>>> 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 <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 <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 <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 <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 <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/ <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




[-- Attachment #1.2: Type: text/html, Size: 17007 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RFC] Code of Conduct

[George Dunlap]

On 8/15/19 6:23 PM, Rich Persaud wrote:
>> On Aug 9, 2019, at 13:48, Lars Kurth <lars.kurth@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?

This is sort of a strange question.

Generally speaking, there was a link Lars pointed to in an earlier
thread in preparation for this, making two suggestions about adopting a CoC:

1. Don't create your own CoC from scratch.  Learn from other people's
experiences, mistakes, and so on, rather than re-inventing the wheel.
This will hopefully reduce the chance of re-hashing mistakes other
communities have made.

2. Don't copy-and-paste a CoC unmodified from another project.  Consider
it, adapt it to your own community culture and situation.  This makes
sure that the CoC is not a tick-box exercise, but that people in your
community have thoughfully considered various issues and genuinely
decided to commit to them.

I think both of those bits of advice are good; and it appears to me that
this is exactly what Lars (with input from a number of others) has done.

There are two things that we want, in general:

1. To cast a vision for what ideal contributor behavior should be

2. To set a bar for minimum acceptable behavior, and a way for excluding
people whose behavior consistently falls below that bar.

One area in particular where Lars thought other CoCs were weak was in
trying to combine #1 and #2.  They need different responses.  #1 needs
encouragement and vision.  #2 needs teeth: We need to be able to apply
penalties and exclude people.

As a result, Lars has suggested (and many people have agreed), that we
separate the two functions.  This document is about #2, not #1.  We plan
to do #1 after #2 is completed.

>> # Expected Behavior
>> All Xen Project community members are expected to behave in accordance with 
>> professional standards, with both the Xen Project Code of Conduct as well as their 
>> respective employer’s policies governing appropriate workplace behavior, and 
>> applicable laws.
> 
> In the x86 community call where this was first discussed, I suggested that we try to define desirable behavior, which we would like to incentivize and promote.   In this current draft, we have a single sentence on positive behavior, with inclusion-by-reference to:

We plan on doing this, but in another document.

> If incorporation-by-reference is not sufficient, e.g. if we will maintain a blacklist of unacceptable behavior for collaborative, online open-source development, do we also need a whitelist of acceptable behavior?  Within Xen source code, we have been moving away from blacklists towards whitelists.

Unlike hypercalls, all human behavior cannot be enumerated; and if it
could, 100% certainty cannot be obtained about what a certain behavior
is, or even exactly what did or did not happen.  No matter what we write
down, at some point, you're just going to have to either trust the
people making the decisions.

>> # Unacceptable Behavior
>> Harassment will not be tolerated in the Xen Project Community in any form, 
>> including but not limited to harassment based on gender, gender identity and 
>> expression, sexual orientation, disability, physical appearance, body size, race, 
>> age, religion, ethnicity, nationality, level of experience, education, or 
>> socio-economic status or any other status protected by laws in jurisdictions in 
>> which community members are based. Harassment includes the use of abusive, 
>> offensive or degrading language, intimidation, stalking, harassing photography 
>> or recording, inappropriate physical contact, sexual imagery and unwelcome 
>> sexual advances, requests for sexual favors, publishing others' private 
>> information such as a physical or electronic address without explicit permission
> 
> Picking one item at random:  would a conference-originated blacklist prohibition be appropriate for online open-source development?  E.g. if someone's email address were included in a xen-devel thread (on the cc line), without obtaining explicit permission, would that be unacceptable behavior for a Xen developer?  That could disqualify much of the current development community.

Suppose Bob has a private email address that he doesn't want to become
public.  Suppose that Alice knows this address, and also knows that Bob
wants this to be private.  And suppose that Alice and purposely CC's
Bob's private email address on a mail to xen-devel in retribution for
something (for instance, because Bob broke up with Alice).

Is that harassment?  Yes, absolutely.

Now, it may sometimes be difficult to determine whether something like
"Alice knew that Bob wanted this private" and "Alice purposely revealed
Bob's address" are true statements or not.  It may be in fact that *Bob*
is raising a false issue with the CoC team in retribution for something
*Alice* has done.

This sort of situation puts the CoC team in a difficult place: If they
don't act, and Alice really was harassing Bob, then they are effectively
enabling Alice's behavior.  People like Bob will leave, and more people
like Alice will come.  If they do act, and Alice wasn't really harassing
Bob, then they are effectively enabling Bob's behavior; people like
Alice will leave, and more people like Bob will come.

Life is often unclear and messy; but that doesn't excuse us from acting.
 We've all got to try to make the best decision we can with limited
information.

>> Any report of harassment within the Xen Project community will be addressed 
>> swiftly. Participants asked to stop any harassing behavior are expected to 
>> comply immediately. Anyone who witnesses or is subjected to unacceptable 
>> behavior should notify the Xen Project’s CoC team via conduct@xenproject.org.
>>
>> # Consequences of Unacceptable Behavior
>> If a participant engages in harassing behavior, the Xen Project’s CoC team may 
>> take any action it deems appropriate, ranging from issuance of a warning to the 
>> offending individual to expulsion from the Xen Project community.
> 
> This is an enforceable action in the physical world, e.g. conference event, but may be more difficult online.  As the existence of spam, bots, robocallers and cyberattack attribution forensics have shown, digital identity is not as clear cut as physical identity at a conference.   It may be better to look for precedent CoC legal clauses that were designed for online contexts.

I think you're overthinking this.  If someone is banned and then creates
a false identity which thereafter behaves in such a way that we cannot
tell it is the original person, then we will still have accomplished our
goal of creating a harassment-free environment.  If someone is banned
and continues to create false identities which continue to misbehave in
the same way as the banned person, then 1) it will be clear who they
are, and 2) we can temporarily prevent new addresses from subscribing to
the list without a second level of approval.

If we really get some sort of persistent troll who just won't go away,
then we can decide what to do at that point.  But I would have
absolutely no regrets about attempting to remove such a person from our
community.

> Let's assume that digital identity can be proven and a person can be expelled from the Xen Project community.  Would this action apply only to the person's digital identity at Company X, or also to their new digital identity at Company Y?  i.e. would behavior and enforcement be scoped to the individual, the company or both?  

Your examples are really contrived.

The goal of the CoC, as stated, is to create a harassment-free
environment.  If person A has done harassing at company X, and we ban
them, then naturally they're banned at company Y as well.

Banning other people at company X will generally not promote
harassment-free environment; but you could imagine situations where it
would.  That would obviously be a drastic step.

> The "Acceptable Behavior" clause includes individual, company and nation-state in scope of governance.  If the "Unacceptable Behavior" clauses would lead to economic harm for a company, e.g. impacting a company's ability to ship a commercial release of  product with Xen Project components, would the company be given an opportunity to improve the behavior of their employee, within the employment context of their work in the collaborative, open-source development of Xen?  What would be due process for such improvement opportunity, in compliance with nation-state labor laws for employee termination?

Not sure what the first sentence has to do with the rest of the
paragraph.  You seem to be muddling up a couple of questions:

1. Will offenders be given opportunity to amend their behavior before
being permanently banned?

2. Can people be given more lenient treatment if they are economically
important to a company?

3. If an employee is banned, does the company have to fire them?

The answer to #1 is, "if possible".  If genuine change and
reconciliation can take place, that's obviously better than expulsion.
Relatively minor violations, where it's clear that expectations were not
understood, would probably only receive a warning.  Serious violations
may require a temporary ban on principle, but "temporary ban" implies
the expectation that things can improve.  Extremely serious violations
may require an immediate permanent ban.

The answer to #2 is, as far as I'm concerned, "absolutely not".

The answer to #3 is, "that's not really any of our business".

> If the "Unacceptable Behavior" clauses would lead to blacklisting of a person's digital and physical identities from the online, collaborative, open-source development community of Xen, would this have a material impact on the ability of that human to find employment in any company or nation-state?  If so, would such a public employment blacklist be compliant with the labor laws of affected nation-states?  

What happens if Xen becomes so ubiquitous our important that not being
able to submit patches or participate in our mailing list means you
can't find a job at all as a software developer at all, in any country
or any company?  I think we'll cross that bridge when we come to it. :-)

More seriously: Yes, if we permanently ban someone from the mailing
list, it's possible they may sue us claiming that it's an illegal
employment blacklist.  Assuming we've only banned people who have either
persistently displayed bad behavior, or displayed extreme behavior at
least once,  I expect the law will be on our side.  If not, we'll have
to figure out how to adapt our policies based on the details of that
particular case.

(If you know of any relevant case law, then of course please share it.)

> If not, would there be dis-incentives for a Xen-contributing company to hire someone who could not participate in the online, collaborative, open-source development community for Xen Project?

Um, yes?  But hopefully a larger dis-incentive would be to hire someone
who had acted in such a way as to get banned in the first place.

Your attitude seems to be, "Oh, what about poor Alice, who has been
banned from the community and now can't get a job working on Xen!"
Don't forget Bob, whom (as far as we can tell) Alice has been
persistently harassing, in spite of repeated warnings to stop.  In such
a situation *one of those two people are going to be excluded*.  If we
do not exclude Alice, then Bob will be excluded from the community by
Alice's behavior (and the rest of us ignoring it).

Assuming that we've investigated the issue and determined that Alice is
the one behaving inappropriately, I'd much rather exclude Alice than Bob.

> Would these considerations influence a company which is selecting a global labor pool of hypervisor talent and open-source hypervisor for their commercial product?  Can we perform a comparative analysis of these scenarios for the proposed Xen Project CoC vs. other OSS hypervisors which compete with Xen?

I firmly believe that a community that insists on minimum standards of
behavior will be "more competitive" than a community which tolerates
toxic behavior because the people who do so seem to get a lot of work done.

But even if that's not the case, I'd rather work in a slightly less
"competitive" community than put up with toxic behavior.

> These are some example scenarios where a conference/event CoC may not be suitable.

I don't see how any of your arguments are particular to conferences.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RFC] Code of Conduct

[Rich Persaud]

[-- Attachment #1.1: Type: text/plain, Size: 15213 bytes --]

On Aug 16, 2019, at 07:19, George Dunlap <george.dunlap@citrix.com> wrote:
> 
> On 8/15/19 6:23 PM, Rich Persaud wrote:
>>> On Aug 9, 2019, at 13:48, Lars Kurth <lars.kurth@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?
> 
> This is sort of a strange question.
> 
> Generally speaking, there was a link Lars pointed to in an earlier
> thread in preparation for this, making two suggestions about adopting a CoC:
> 
> 1. Don't create your own CoC from scratch.  Learn from other people's
> experiences, mistakes, and so on, rather than re-inventing the wheel.
> This will hopefully reduce the chance of re-hashing mistakes other
> communities have made.
> 
> 2. Don't copy-and-paste a CoC unmodified from another project.  Consider
> it, adapt it to your own community culture and situation.  This makes
> sure that the CoC is not a tick-box exercise, but that people in your
> community have thoughfully considered various issues and genuinely
> decided to commit to them.
> 
> I think both of those bits of advice are good; and it appears to me that
> this is exactly what Lars (with input from a number of others) has done.
> 
> There are two things that we want, in general:
> 
> 1. To cast a vision for what ideal contributor behavior should be
> 
> 2. To set a bar for minimum acceptable behavior, and a way for excluding
> people whose behavior consistently falls below that bar.
> 
> One area in particular where Lars thought other CoCs were weak was in
> trying to combine #1 and #2.  They need different responses.  #1 needs
> encouragement and vision.  #2 needs teeth: We need to be able to apply
> penalties and exclude people.
> 
> As a result, Lars has suggested (and many people have agreed), that we
> separate the two functions.  This document is about #2, not #1.  We plan
> to do #1 after #2 is completed.
> 
>>> # Expected Behavior
>>> All Xen Project community members are expected to behave in accordance with 
>>> professional standards, with both the Xen Project Code of Conduct as well as their 
>>> respective employer’s policies governing appropriate workplace behavior, and 
>>> applicable laws.
>> 
>> In the x86 community call where this was first discussed, I suggested that we try to define desirable behavior, which we would like to incentivize and promote.   In this current draft, we have a single sentence on positive behavior, with inclusion-by-reference to:
> 
> We plan on doing this, but in another document.
> 
>> If incorporation-by-reference is not sufficient, e.g. if we will maintain a blacklist of unacceptable behavior for collaborative, online open-source development, do we also need a whitelist of acceptable behavior?  Within Xen source code, we have been moving away from blacklists towards whitelists.
> 
> Unlike hypercalls, all human behavior cannot be enumerated; and if it
> could, 100% certainty cannot be obtained about what a certain behavior
> is, or even exactly what did or did not happen.  No matter what we write
> down, at some point, you're just going to have to either trust the
> people making the decisions.
> 
>>> # Unacceptable Behavior
>>> Harassment will not be tolerated in the Xen Project Community in any form, 
>>> including but not limited to harassment based on gender, gender identity and 
>>> expression, sexual orientation, disability, physical appearance, body size, race, 
>>> age, religion, ethnicity, nationality, level of experience, education, or 
>>> socio-economic status or any other status protected by laws in jurisdictions in 
>>> which community members are based. Harassment includes the use of abusive, 
>>> offensive or degrading language, intimidation, stalking, harassing photography 
>>> or recording, inappropriate physical contact, sexual imagery and unwelcome 
>>> sexual advances, requests for sexual favors, publishing others' private 
>>> information such as a physical or electronic address without explicit permission
>> 
>> Picking one item at random:  would a conference-originated blacklist prohibition be appropriate for online open-source development?  E.g. if someone's email address were included in a xen-devel thread (on the cc line), without obtaining explicit permission, would that be unacceptable behavior for a Xen developer?  That could disqualify much of the current development community.
> 
> Suppose Bob has a private email address that he doesn't want to become
> public.  Suppose that Alice knows this address, and also knows that Bob
> wants this to be private.  And suppose that Alice and purposely CC's
> Bob's private email address on a mail to xen-devel in retribution for
> something (for instance, because Bob broke up with Alice).
> 
> Is that harassment?  Yes, absolutely.
> 
> Now, it may sometimes be difficult to determine whether something like
> "Alice knew that Bob wanted this private" and "Alice purposely revealed
> Bob's address" are true statements or not.  It may be in fact that *Bob*
> is raising a false issue with the CoC team in retribution for something
> *Alice* has done.
> 
> This sort of situation puts the CoC team in a difficult place: If they
> don't act, and Alice really was harassing Bob, then they are effectively
> enabling Alice's behavior.  People like Bob will leave, and more people
> like Alice will come.  If they do act, and Alice wasn't really harassing
> Bob, then they are effectively enabling Bob's behavior; people like
> Alice will leave, and more people like Bob will come.
> 
> Life is often unclear and messy; but that doesn't excuse us from acting.
> We've all got to try to make the best decision we can with limited
> information.
> 
>>> Any report of harassment within the Xen Project community will be addressed 
>>> swiftly. Participants asked to stop any harassing behavior are expected to 
>>> comply immediately. Anyone who witnesses or is subjected to unacceptable 
>>> behavior should notify the Xen Project’s CoC team via conduct@xenproject.org.
>>> 
>>> # Consequences of Unacceptable Behavior
>>> If a participant engages in harassing behavior, the Xen Project’s CoC team may 
>>> take any action it deems appropriate, ranging from issuance of a warning to the 
>>> offending individual to expulsion from the Xen Project community.
>> 
>> This is an enforceable action in the physical world, e.g. conference event, but may be more difficult online.  As the existence of spam, bots, robocallers and cyberattack attribution forensics have shown, digital identity is not as clear cut as physical identity at a conference.   It may be better to look for precedent CoC legal clauses that were designed for online contexts.
> 
> I think you're overthinking this.  If someone is banned and then creates
> a false identity which thereafter behaves in such a way that we cannot
> tell it is the original person, then we will still have accomplished our
> goal of creating a harassment-free environment.  If someone is banned
> and continues to create false identities which continue to misbehave in
> the same way as the banned person, then 1) it will be clear who they
> are, and 2) we can temporarily prevent new addresses from subscribing to
> the list without a second level of approval.
> 
> If we really get some sort of persistent troll who just won't go away,
> then we can decide what to do at that point.  But I would have
> absolutely no regrets about attempting to remove such a person from our
> community.
> 
>> Let's assume that digital identity can be proven and a person can be expelled from the Xen Project community.  Would this action apply only to the person's digital identity at Company X, or also to their new digital identity at Company Y?  i.e. would behavior and enforcement be scoped to the individual, the company or both?  
> 
> Your examples are really contrived.
> 
> The goal of the CoC, as stated, is to create a harassment-free
> environment.  If person A has done harassing at company X, and we ban
> them, then naturally they're banned at company Y as well.
> 
> Banning other people at company X will generally not promote
> harassment-free environment; but you could imagine situations where it
> would.  That would obviously be a drastic step.
> 
>> The "Acceptable Behavior" clause includes individual, company and nation-state in scope of governance.  If the "Unacceptable Behavior" clauses would lead to economic harm for a company, e.g. impacting a company's ability to ship a commercial release of  product with Xen Project components, would the company be given an opportunity to improve the behavior of their employee, within the employment context of their work in the collaborative, open-source development of Xen?  What would be due process for such improvement opportunity, in compliance with nation-state labor laws for employee termination?
> 
> Not sure what the first sentence has to do with the rest of the
> paragraph.  You seem to be muddling up a couple of questions:
> 
> 1. Will offenders be given opportunity to amend their behavior before
> being permanently banned?
> 
> 2. Can people be given more lenient treatment if they are economically
> important to a company?
> 
> 3. If an employee is banned, does the company have to fire them?
> 
> The answer to #1 is, "if possible".  If genuine change and
> reconciliation can take place, that's obviously better than expulsion.
> Relatively minor violations, where it's clear that expectations were not
> understood, would probably only receive a warning.  Serious violations
> may require a temporary ban on principle, but "temporary ban" implies
> the expectation that things can improve.  Extremely serious violations
> may require an immediate permanent ban.
> 
> The answer to #2 is, as far as I'm concerned, "absolutely not".
> 
> The answer to #3 is, "that's not really any of our business".
> 
>> If the "Unacceptable Behavior" clauses would lead to blacklisting of a person's digital and physical identities from the online, collaborative, open-source development community of Xen, would this have a material impact on the ability of that human to find employment in any company or nation-state?  If so, would such a public employment blacklist be compliant with the labor laws of affected nation-states?  
> 
> What happens if Xen becomes so ubiquitous our important that not being
> able to submit patches or participate in our mailing list means you
> can't find a job at all as a software developer at all, in any country
> or any company?  I think we'll cross that bridge when we come to it. :-)
> 
> More seriously: Yes, if we permanently ban someone from the mailing
> list, it's possible they may sue us claiming that it's an illegal
> employment blacklist.  Assuming we've only banned people who have either
> persistently displayed bad behavior, or displayed extreme behavior at
> least once,  I expect the law will be on our side.  If not, we'll have
> to figure out how to adapt our policies based on the details of that
> particular case.
> 
> (If you know of any relevant case law, then of course please share it.)
> 
>> If not, would there be dis-incentives for a Xen-contributing company to hire someone who could not participate in the online, collaborative, open-source development community for Xen Project?
> 
> Um, yes?  But hopefully a larger dis-incentive would be to hire someone
> who had acted in such a way as to get banned in the first place.
> 
> Your attitude seems to be, "Oh, what about poor Alice, who has been
> banned from the community and now can't get a job working on Xen!"
> Don't forget Bob, whom (as far as we can tell) Alice has been
> persistently harassing, in spite of repeated warnings to stop.  In such
> a situation *one of those two people are going to be excluded*.  If we
> do not exclude Alice, then Bob will be excluded from the community by
> Alice's behavior (and the rest of us ignoring it).
> 
> Assuming that we've investigated the issue and determined that Alice is
> the one behaving inappropriately, I'd much rather exclude Alice than Bob.
> 
>> Would these considerations influence a company which is selecting a global labor pool of hypervisor talent and open-source hypervisor for their commercial product?  Can we perform a comparative analysis of these scenarios for the proposed Xen Project CoC vs. other OSS hypervisors which compete with Xen?
> 
> I firmly believe that a community that insists on minimum standards of
> behavior will be "more competitive" than a community which tolerates
> toxic behavior because the people who do so seem to get a lot of work done.
> 
> But even if that's not the case, I'd rather work in a slightly less
> "competitive" community than put up with toxic behavior.
> 
>> These are some example scenarios where a conference/event CoC may not be suitable.
> 
> I don't see how any of your arguments are particular to conferences.
> 
> -George

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

[-- Attachment #1.2: Type: text/html, Size: 22544 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RFC] Code of Conduct

[Lars Kurth]

[-- Attachment #1.1: Type: text/plain, Size: 2260 bytes --]



From: Rich Persaud <persaur@gmail.com>
Date: Friday, 16 August 2019 at 16:49
To: George Dunlap <George.Dunlap@citrix.com>
Cc: Lars Kurth <lars.kurth@citrix.com>, xen-devel <xen-devel@lists.xenproject.org>, "minios-devel@lists.xenproject.org" <minios-devel@lists.xenproject.org>, "mirageos-devel@lists.xenproject.org" <mirageos-devel@lists.xenproject.org>, "win-pv-devel@lists.xenproject.org" <win-pv-devel@lists.xenproject.org>, "committers@xenproject.org" <committers@xenproject.org>
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

[-- Attachment #1.2: Type: text/html, Size: 8735 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RFC] Code of Conduct

[Lars Kurth]

[-- Attachment #1.1: Type: text/plain, Size: 3364 bytes --]



From: Rich Persaud <persaur@gmail.com>
Date: Friday, 16 August 2019 at 16:49
To: George Dunlap <George.Dunlap@citrix.com>
Cc: Lars Kurth <lars.kurth@citrix.com>, xen-devel <xen-devel@lists.xenproject.org>, "minios-devel@lists.xenproject.org" <minios-devel@lists.xenproject.org>, "mirageos-devel@lists.xenproject.org" <mirageos-devel@lists.xenproject.org>, "win-pv-devel@lists.xenproject.org" <win-pv-devel@lists.xenproject.org>, "committers@xenproject.org" <committers@xenproject.org>
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:

  1.  We wait for the LF and revisit then
  2.  We go our own way re customization
  3.  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


[-- Attachment #1.2: Type: text/html, Size: 14895 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RFC] Code of Conduct

[Ian Jackson]

Lars Kurth writes ("Re: [Xen-devel] [RFC] Code of Conduct"):
> 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.

I think this is too long.  We are overdue with this.

> Ultimately, we have 3 options:
> 
>   1.  We wait for the LF and revisit then
>   2.  We go our own way re customization
>   3.  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

I am happy with 2 or 3, but we shouldn't block on LF approval.  Having
input is good.  If later we want to join some cross-community network
and want to update it for that, we can do that.  Updating a document
for something like that is quite easy.  IMO we need to get on with the
really hard work which is adopting a document at all.

I look forward to your Contributor Covenant based draft.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RFC] Code of Conduct

[Lars Kurth]

[-- Attachment #1: Type: text/plain, Size: 2003 bytes --]



On 27/08/2019, 10:33, "Ian Jackson" <ian.jackson@citrix.com> wrote:

    Lars Kurth writes ("Re: [Xen-devel] [RFC] Code of Conduct"):
    > 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.
    
    I think this is too long.  We are overdue with this.
    
    > Ultimately, we have 3 options:
    > 
    >   1.  We wait for the LF and revisit then
    >   2.  We go our own way re customization
    >   3.  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
    
    I am happy with 2 or 3, but we shouldn't block on LF approval.  Having
    input is good.  If later we want to join some cross-community network
    and want to update it for that, we can do that.  Updating a document
    for something like that is quite easy.  IMO we need to get on with the
    really hard work which is adopting a document at all.

That is also my personal preference.
    
    I look forward to your Contributor Covenant based draft.
    
I attached a redline version of both the original (based on the LF events CoC) and a redline version based on the covenant given the constraints we agreed. Aka
[1] Xen CoC Contributor Covenant baseline (redline).pdf 
[2] Xen CoC LF events baseline (redline).pdf

I minimized changes to [2]. 

I would be good to get a sense of whether anyone prefers one over the other or whether additional changes should made to [2], but also [1]. In the thread there had already been concrete suggestions to remove sections such as comments along the lines of compliance with local laws.

I will disclose my personal opinion a little later. 

Best Regards
Lars


[-- Attachment #2: Xen CoC Contributor Covenant baseline (redline).pdf --]
[-- Type: application/pdf, Size: 40907 bytes --]

[-- Attachment #3: Xen CoC LF events baseline (redline).pdf --]
[-- Type: application/pdf, Size: 70783 bytes --]

[-- Attachment #4: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RFC] Code of Conduct

[Stefano Stabellini]

[-- Attachment #1: Type: text/plain, Size: 3057 bytes --]

On Tue, 27 Aug 2019, Lars Kurth wrote:
> On 27/08/2019, 10:33, "Ian Jackson" <ian.jackson@citrix.com> wrote:
> 
>     Lars Kurth writes ("Re: [Xen-devel] [RFC] Code of Conduct"):
>     > 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.
>     
>     I think this is too long.  We are overdue with this.
>     
>     > Ultimately, we have 3 options:
>     > 
>     >   1.  We wait for the LF and revisit then
>     >   2.  We go our own way re customization
>     >   3.  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
>     
>     I am happy with 2 or 3, but we shouldn't block on LF approval.  Having
>     input is good.  If later we want to join some cross-community network
>     and want to update it for that, we can do that.  Updating a document
>     for something like that is quite easy.  IMO we need to get on with the
>     really hard work which is adopting a document at all.
> 
> That is also my personal preference.
>     
>     I look forward to your Contributor Covenant based draft.
>     
> I attached a redline version of both the original (based on the LF events CoC) and a redline version based on the covenant given the constraints we agreed. Aka
> [1] Xen CoC Contributor Covenant baseline (redline).pdf 
> [2] Xen CoC LF events baseline (redline).pdf
> 
> I minimized changes to [2]. 
> 
> I would be good to get a sense of whether anyone prefers one over the other or whether additional changes should made to [2], but also [1]. In the thread there had already been concrete suggestions to remove sections such as comments along the lines of compliance with local laws.
> 
> I will disclose my personal opinion a little later. 

Honestly they look both very reasonable and I would be happy with either
of them. I agree with you and Ian that it would be best not to wait for
months, but to try to get it adopted soon.

It is surprising how few changes you had to make to the Contributor
Covenant baseline. Also both end results look so similar that I can
hardly distinguish them in terms of content.

A couple of comments on the Contributor Covenant based one:
- not sure if we still need the examples of positive behavior under "Our
  Standards" by they don't hurt
- Under "Our Responsibilites" the text keeps repeating "Project
  maintainers" while actually we probably want to mention the CoC team
  also (for instance "and are expected, together with the CoC team, to
  take appropriate and fair corrective action in response to").

At this point I might be tempted to suggest to use the one based on the
Contributor Covenant just because the changes are fewer, but I am happy
to leave the decision to you and what you think is best.

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RFC] Code of Conduct

[Lars Kurth]

On 27/08/2019, 17:54, "Stefano Stabellini" <sstabellini@kernel.org> wrote:

    On Tue, 27 Aug 2019, Lars Kurth wrote:
    > On 27/08/2019, 10:33, "Ian Jackson" <ian.jackson@citrix.com> wrote:
    > 
    >     Lars Kurth writes ("Re: [Xen-devel] [RFC] Code of Conduct"):
    >     > 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.
    >     
    >     I think this is too long.  We are overdue with this.
    >     
    >     > Ultimately, we have 3 options:
    >     > 
    >     >   1.  We wait for the LF and revisit then
    >     >   2.  We go our own way re customization
    >     >   3.  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
    >     
    >     I am happy with 2 or 3, but we shouldn't block on LF approval.  Having
    >     input is good.  If later we want to join some cross-community network
    >     and want to update it for that, we can do that.  Updating a document
    >     for something like that is quite easy.  IMO we need to get on with the
    >     really hard work which is adopting a document at all.
    > 
    > That is also my personal preference.
    >     
    >     I look forward to your Contributor Covenant based draft.
    >     
    > I attached a redline version of both the original (based on the LF events CoC) and a redline version based on the covenant given the constraints we agreed. Aka
    > [1] Xen CoC Contributor Covenant baseline (redline).pdf 
    > [2] Xen CoC LF events baseline (redline).pdf
    > 
    > I minimized changes to [2]. 
    > 
    > I would be good to get a sense of whether anyone prefers one over the other or whether additional changes should made to [2], but also [1]. In the thread there had already been concrete suggestions to remove sections such as comments along the lines of compliance with local laws.
    > 
    > I will disclose my personal opinion a little later. 
    
    Honestly they look both very reasonable and I would be happy with either
    of them. I agree with you and Ian that it would be best not to wait for
    months, but to try to get it adopted soon.
    
    It is surprising how few changes you had to make to the Contributor
    Covenant baseline. Also both end results look so similar that I can
    hardly distinguish them in terms of content.
    
    A couple of comments on the Contributor Covenant based one:
    - not sure if we still need the examples of positive behavior under "Our
      Standards" by they don't hurt
    - Under "Our Responsibilites" the text keeps repeating "Project
      maintainers" while actually we probably want to mention the CoC team
      also (for instance "and are expected, together with the CoC team, to
      take appropriate and fair corrective action in response to").

Thanks for pointing that out
    
    At this point I might be tempted to suggest to use the one based on the
    Contributor Covenant just because the changes are fewer, but I am happy
    to leave the decision to you and what you think is best.

It does look very similar. I intentionally made very few changes to the CC as the volume of change was a criticism of the earlier attempt. Generally, I feel the text of the covenant is not as clear as the other version. But that is merely a style issue in that reading through it doesn't flow as well as is in the other version. But that is clearly not as important as staying close to the original.

We could also made further changes and for example say under enforcement: "Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the Xen Project’s CoC team at conduct@xenproject.org *which is made up of project leadership team members*" or something like it. This would clarify that we are not introducing a new election process.

Also, the examples of positive behaviour under "Our Standards" don't gel very well with the section inserted afterwards. This could be addressed by canning the positive example section and replacing it with what I inserted underneath. 

What I forgot to mention was that we will try and build on https://www.slideshare.net/xen_com_mgr/xpdds19-keynote-patch-review-for-nonmaintainers-george-dunlap-citrix-systems-uk-ltd for the separate document to encourage positive behaviour (when I started the thread the slides had not been published). 

Also, a number of very good suggestion was made in the discussion we had at Security Summit around fostering positive behaviour. The intention I have is for this to have 3 elements:
* Documentation to set expectations, share tips and best practices - with the hope that people in the community reflect occasionally on how they are doing against these (or are maybe prompted by peers to do so) 
* A safe back-channel to ask for advice when a conversation becomes inefficient, unactionable, is unfriendly, ... with a view to recover it
* Arbitration in cases where there is some friction amongst participants in a discussion, which was not resolvable by any of the before. After all, when this happens there is a risk that a working relationship gets negatively impacted. It is actually in the interest of each participant to improve to avoid friction, stress, etc. 

Of course, the idea is that we will not have to use any of this much    

Regards
Lars

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RFC] Code of Conduct

[Ian Jackson]

Lars Kurth writes ("Re: [Xen-devel] [RFC] Code of Conduct"):
> I attached a redline version of both the original (based on the LF events CoC) and a redline version based on the covenant given the constraints we agreed. Aka
> [1] Xen CoC Contributor Covenant baseline (redline).pdf 
> [2] Xen CoC LF events baseline (redline).pdf
> 
> I minimized changes to [2]. 

I like both of these.  I would be happy to adopt either.  I prefer the
Contributor Covenant based version.


I have two comments.  The first is very minor:

The LF Events one has one different section title.  Instead of
        Enforcement
it has
        What To Do If You Witness Or Are Subject To Unacceptable
        Behavior 
which is unwieldy but better in other ways - more positive and
constructive.  I'm not sure if there is a happy middle ground.
I am happy to adopt either version with either title.  I mention it in
case anyone has better ideas etc.


My second comment is more substantial.  It should not be regarded as a
blocker, but I would like to see it addressed either now or after CoC
adoption.

The root issue is the difficult one of what to do about possible
involvement in abuse by members of the conduct@ address.

I would like to see two changes: firstly, we should publish the list
of people that the conduct alias goes to.  The CoC should contain a
reference to the place where this can be found.  "The membership of
the conduct@ alias is publicly documented in [location]".

Secondly, we should explicitly provide a route for someone who
distrusts member(s) of conduct@.  How about:

  If you have concerns about any of the members of the conduct@ alias,
  you are welcome to contact precisely the Conduct Team member(s) of
  your choice.

The team should be large and diverse enough that this is a practically
useful recommendation, but it should not be unwieldy.


Thanks for driving this.

Regards,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RFC] Code of Conduct

[Lars Kurth]

On 02/09/2019, 16:49, "Ian Jackson" <ian.jackson@citrix.com> wrote:

    Lars Kurth writes ("Re: [Xen-devel] [RFC] Code of Conduct"):
    > I attached a redline version of both the original (based on the LF events CoC) and a redline version based on the covenant given the constraints we agreed. Aka
    > [1] Xen CoC Contributor Covenant baseline (redline).pdf 
    > [2] Xen CoC LF events baseline (redline).pdf
    > 
    > I minimized changes to [2]. 
    
    I like both of these.  I would be happy to adopt either.  I prefer the
    Contributor Covenant based version.
    
    
    I have two comments.  The first is very minor:
    
    The LF Events one has one different section title.  Instead of
            Enforcement
    it has
            What To Do If You Witness Or Are Subject To Unacceptable
            Behavior 
    which is unwieldy but better in other ways - more positive and
    constructive.  I'm not sure if there is a happy middle ground.
    I am happy to adopt either version with either title.  I mention it in
    case anyone has better ideas etc.

I am also altogether happier with the Contributor Covenant, but maybe 
with a few additional changes such as changing some titles and some
of the modifications outlined earlier.
    
    My second comment is more substantial.  It should not be regarded as a
    blocker, but I would like to see it addressed either now or after CoC
    adoption.
    
    The root issue is the difficult one of what to do about possible
    involvement in abuse by members of the conduct@ address.
    
    I would like to see two changes: firstly, we should publish the list
    of people that the conduct alias goes to.  The CoC should contain a
    reference to the place where this can be found.  "The membership of
    the conduct@ alias is publicly documented in [location]".

That is entirely sensible. I think the best place would be to record this
in the document. We should probably start with a shortlist of people 
and include it in the next version and get it all approved in one go
    
    Secondly, we should explicitly provide a route for someone who
    distrusts member(s) of conduct@.  How about:
    
      If you have concerns about any of the members of the conduct@ alias,
      you are welcome to contact precisely the Conduct Team member(s) of
      your choice.

That is entirely fine with me.
    
    The team should be large and diverse enough that this is a practically
    useful recommendation, but it should not be unwieldy.
    
I was thinking of 2-3 maybe 4 people. Can those leadership team members
who are willing to step up reply to me privately or in this thread. I am assuming 
that I will be a member of conduct@, but I am also willing to step aside
if it helps.

Regardless of this, I think I have enough to send out a concrete proposal
for further review

Best Regards
Lars


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RFC] Code of Conduct

[George Dunlap]

On 8/9/19 6:48 PM, Lars Kurth wrote:
> Hi all,
> 
> 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.
> 
> You can provide feedback by commenting on the google doc or by replying to the in-lined version below. 
> I expect it will some more discussion to get consensus. 
> 
> Note that I am not very attached to some of the terms, such as "Xen Project CoC  Team" and in some cases "participant" should probably be replaced by community 
> members. 
> 
> But I felt, we should have something more concrete to discuss compared to previous discussions.
> 
> A Code of Conduct is a project wide policy change: thus, all subprojects lists are CC'ed

Thanks for doing this Lars.  I think this is a step forward.

I have a couple of comments, but only on the wording.

> 
> Regards
> Lars
> 
> Here is the actual text
> ---
> # Our Pledge
> In the interest of fostering an open and welcoming environment, we as community 
> members of the Xen Project pledge to making participation in our project and our 
> community a harassment-free experience for everyone.

To me "pledge" means "promise"; and I don't think we can promise anyone
that they'll have a harassment-free experience.  I might say, "we ...
are committed to making participation ... a harassment-free experience";
or "we ... pledge to maintain a harassment-free experience" or something
like that.

> # Unacceptable Behavior
> Harassment will not be tolerated in the Xen Project Community in any form, 
> including but not limited to harassment based on gender, gender identity and 
> expression, sexual orientation, disability, physical appearance, body size, race, 
> age, religion, ethnicity, nationality, level of experience, education, or 
> socio-economic status or any other status protected by laws in jurisdictions in 
> which community members are based.

> Harassment includes the use of abusive, 
> offensive or degrading language, intimidation, stalking, harassing photography 
> or recording, inappropriate physical contact, sexual imagery and unwelcome 
> sexual advances, requests for sexual favors, publishing others' private 
> information such as a physical or electronic address without explicit permission 
> and other conduct which could reasonably be considered inappropriate in a 
> professional setting. 

Should we put "such as physical or electronic address[es]" in parentheses?

Also, I'm in favor of the Oxford Comma (so a comma after 'permission').

I might say "or any other conduct"; for some reason it sounds more
natural to me.

> Any report of harassment within the Xen Project community will be addressed 
> swiftly. Participants asked to stop any harassing behavior are expected to 
> comply immediately. Anyone who witnesses or is subjected to unacceptable 
> behavior should notify the Xen Project’s CoC team via conduct@xenproject.org.
> 
> # Consequences of Unacceptable Behavior
> If a participant engages in harassing behavior, the Xen Project’s CoC team may 
> take any action it deems appropriate, ranging from issuance of a warning to the 
> offending individual to expulsion from the Xen Project community.

I realize by saying "range" you probably meant to include this, but I
think spelling out "temporary suspension" as a possible consequence.  E.g.:

"If a participant engages in harassing behavior, the Xen Project's CoC
team will investigate and take an action it deems appropriate against
the offending individual.  This may include issuing a warning, temporary
suspension from mailing lists or commit rights, or expulsion from the
XenProject community."

That's all I had; thanks again, Lars.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RFC] Code of Conduct

[Lars Kurth]

Hi George,

On 12/08/2019, 12:35, "George Dunlap" <george.dunlap@citrix.com> wrote:

    On 8/9/19 6:48 PM, Lars Kurth wrote:
    > Hi all,
    > 
    > 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.
    > 
    > You can provide feedback by commenting on the google doc or by replying to the in-lined version below. 
    > I expect it will some more discussion to get consensus. 
    > 
    > Note that I am not very attached to some of the terms, such as "Xen Project CoC  Team" and in some cases "participant" should probably be replaced by community 
    > members. 
    > 
    > But I felt, we should have something more concrete to discuss compared to previous discussions.
    > 
    > A Code of Conduct is a project wide policy change: thus, all subprojects lists are CC'ed
    
    Thanks for doing this Lars.  I think this is a step forward.
    
    I have a couple of comments, but only on the wording.
    
    > 
    > Regards
    > Lars
    > 
    > Here is the actual text
    > ---
    > # Our Pledge
    > In the interest of fostering an open and welcoming environment, we as community 
    > members of the Xen Project pledge to making participation in our project and our 
    > community a harassment-free experience for everyone.
    
    To me "pledge" means "promise"; and I don't think we can promise anyone
    that they'll have a harassment-free experience.  I might say, "we ...
    are committed to making participation ... a harassment-free experience";
    or "we ... pledge to maintain a harassment-free experience" or something
    like that.

This comes directly from the Contributor Covenant v1.4
But I also like "we ... are committed to making participation ... a harassment-free 
experience" better then pledge.
    
    > # Unacceptable Behavior
    > Harassment will not be tolerated in the Xen Project Community in any form, 
    > including but not limited to harassment based on gender, gender identity and 
    > expression, sexual orientation, disability, physical appearance, body size, race, 
    > age, religion, ethnicity, nationality, level of experience, education, or 
    > socio-economic status or any other status protected by laws in jurisdictions in 
    > which community members are based.
    
    > Harassment includes the use of abusive, 
    > offensive or degrading language, intimidation, stalking, harassing photography 
    > or recording, inappropriate physical contact, sexual imagery and unwelcome 
    > sexual advances, requests for sexual favors, publishing others' private 
    > information such as a physical or electronic address without explicit permission 
    > and other conduct which could reasonably be considered inappropriate in a 
    > professional setting. 
    
    Should we put "such as physical or electronic address[es]" in parentheses?

Fine with me
    
    Also, I'm in favor of the Oxford Comma (so a comma after 'permission').
    
    I might say "or any other conduct"; for some reason it sounds more
    natural to me.

Either works
    
    > Any report of harassment within the Xen Project community will be addressed 
    > swiftly. Participants asked to stop any harassing behavior are expected to 
    > comply immediately. Anyone who witnesses or is subjected to unacceptable 
    > behavior should notify the Xen Project’s CoC team via conduct@xenproject.org.
    > 
    > # Consequences of Unacceptable Behavior
    > If a participant engages in harassing behavior, the Xen Project’s CoC team may 
    > take any action it deems appropriate, ranging from issuance of a warning to the 
    > offending individual to expulsion from the Xen Project community.
    
    I realize by saying "range" you probably meant to include this, but I
    think spelling out "temporary suspension" as a possible consequence.  E.g.:
    
    "If a participant engages in harassing behavior, the Xen Project's CoC
    team will investigate and take an action it deems appropriate against
    the offending individual.  This may include issuing a warning, temporary
    suspension from mailing lists or commit rights, or expulsion from the
    XenProject community."

That looks good
    
    That's all I had; thanks again, Lars.

I am wondering how you feel about the usage of  "participant". There are 
a few instances left in the text. 

"Any report of harassment within the Xen Project community will be addressed
swiftly. Participants asked to stop ..."

# Consequences of Unacceptable Behavior
If a participant engages in harassing behaviour

I would probably also want to replace this with "Community member asked ..." and "If a community member engages in ..."

Regards
Lars

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RFC] Code of Conduct

[George Dunlap]

On 8/12/19 3:27 PM, Lars Kurth wrote:
> I am wondering how you feel about the usage of  "participant". There are 
> a few instances left in the text. 
> 
> "Any report of harassment within the Xen Project community will be addressed
> swiftly. Participants asked to stop ..."
> 
> # Consequences of Unacceptable Behavior
> If a participant engages in harassing behaviour
> 
> I would probably also want to replace this with "Community member asked ..." and "If a community member engages in ..."

Seems reasonable to me.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RFC] Code of Conduct

[Lars Kurth]

Perfect: I updated this also in the google doc. I will leave the review open for a week or two (we do have summer holidays after all) and let people comment. I can then send a proper proposal, followed by a vote
Lars

On 12/08/2019, 15:35, "George Dunlap" <george.dunlap@citrix.com> wrote:

    On 8/12/19 3:27 PM, Lars Kurth wrote:
    > I am wondering how you feel about the usage of  "participant". There are 
    > a few instances left in the text. 
    > 
    > "Any report of harassment within the Xen Project community will be addressed
    > swiftly. Participants asked to stop ..."
    > 
    > # Consequences of Unacceptable Behavior
    > If a participant engages in harassing behaviour
    > 
    > I would probably also want to replace this with "Community member asked ..." and "If a community member engages in ..."
    
    Seems reasonable to me.
    
     -George
    

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel