Xen-Devel Archive on lore.kernel.org
 help / color / Atom feed
* Re: [Xen-devel] [RFC] Code of Conduct
       [not found] <AB34D39A-A120-440E-9309-3950E7A465A5@citrix.com-0>
@ 2019-08-12 11:35 ` George Dunlap
  2019-08-12 14:27   ` Lars Kurth
  0 siblings, 1 reply; 19+ messages in thread
From: George Dunlap @ 2019-08-12 11:35 UTC (permalink / raw)
  To: Lars Kurth, xen-devel, minios-devel, mirageos-devel, win-pv-devel
  Cc: committers

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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [Xen-devel] [RFC] Code of Conduct
  2019-08-12 11:35 ` [Xen-devel] [RFC] Code of Conduct George Dunlap
@ 2019-08-12 14:27   ` Lars Kurth
  2019-08-12 14:35     ` George Dunlap
  0 siblings, 1 reply; 19+ messages in thread
From: Lars Kurth @ 2019-08-12 14:27 UTC (permalink / raw)
  To: George Dunlap, xen-devel, minios-devel, mirageos-devel, win-pv-devel
  Cc: committers

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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [Xen-devel] [RFC] Code of Conduct
  2019-08-12 14:27   ` Lars Kurth
@ 2019-08-12 14:35     ` George Dunlap
  2019-08-13 14:30       ` Lars Kurth
  0 siblings, 1 reply; 19+ messages in thread
From: George Dunlap @ 2019-08-12 14:35 UTC (permalink / raw)
  To: Lars Kurth, xen-devel, minios-devel, mirageos-devel, win-pv-devel
  Cc: committers

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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [Xen-devel] [RFC] Code of Conduct
  2019-08-12 14:35     ` George Dunlap
@ 2019-08-13 14:30       ` Lars Kurth
  0 siblings, 0 replies; 19+ messages in thread
From: Lars Kurth @ 2019-08-13 14:30 UTC (permalink / raw)
  To: George Dunlap, xen-devel, minios-devel, mirageos-devel, win-pv-devel
  Cc: committers

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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [Xen-devel] [RFC] Code of Conduct
  2019-09-02 15:48               ` Ian Jackson
@ 2019-09-02 18:10                 ` Lars Kurth
  0 siblings, 0 replies; 19+ messages in thread
From: Lars Kurth @ 2019-09-02 18:10 UTC (permalink / raw)
  To: Ian Jackson
  Cc: George Dunlap, minios-devel, Rich Persaud, committers,
	mirageos-devel, xen-devel, win-pv-devel, Stefano Stabellini



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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [Xen-devel] [RFC] Code of Conduct
       [not found]             ` <D8EFC0B6-0FFC-4288-86EC-FD0A0BB8C3BF@citrix.com-0>
@ 2019-09-02 15:48               ` Ian Jackson
  2019-09-02 18:10                 ` Lars Kurth
  0 siblings, 1 reply; 19+ messages in thread
From: Ian Jackson @ 2019-09-02 15:48 UTC (permalink / raw)
  To: Lars Kurth
  Cc: George Dunlap, minios-devel, Rich Persaud, committers,
	mirageos-devel, xen-devel, Ian Jackson, win-pv-devel,
	Stefano Stabellini

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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [Xen-devel] [RFC] Code of Conduct
  2019-08-28  0:53               ` Stefano Stabellini
@ 2019-08-28  2:02                 ` Lars Kurth
  0 siblings, 0 replies; 19+ messages in thread
From: Lars Kurth @ 2019-08-28  2:02 UTC (permalink / raw)
  To: Stefano Stabellini
  Cc: George Dunlap, minios-devel, Rich Persaud, committers,
	mirageos-devel, xen-devel, Ian Jackson, win-pv-devel,
	Stefano Stabellini



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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [Xen-devel] [RFC] Code of Conduct
  2019-08-27 20:47             ` Lars Kurth
@ 2019-08-28  0:53               ` Stefano Stabellini
  2019-08-28  2:02                 ` Lars Kurth
  0 siblings, 1 reply; 19+ messages in thread
From: Stefano Stabellini @ 2019-08-28  0:53 UTC (permalink / raw)
  To: Lars Kurth
  Cc: George Dunlap, minios-devel, Rich Persaud, committers,
	mirageos-devel, xen-devel, Ian Jackson, win-pv-devel,
	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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [Xen-devel] [RFC] Code of Conduct
  2019-08-27 17:33           ` Ian Jackson
@ 2019-08-27 20:47             ` Lars Kurth
  2019-08-28  0:53               ` Stefano Stabellini
       [not found]             ` <D8EFC0B6-0FFC-4288-86EC-FD0A0BB8C3BF@citrix.com-0>
  1 sibling, 1 reply; 19+ messages in thread
From: Lars Kurth @ 2019-08-27 20:47 UTC (permalink / raw)
  To: Ian Jackson
  Cc: George Dunlap, minios-devel, Rich Persaud, committers,
	mirageos-devel, xen-devel, win-pv-devel, Stefano Stabellini

[-- 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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [Xen-devel] [RFC] Code of Conduct
  2019-08-26 18:03         ` Lars Kurth
@ 2019-08-27 17:33           ` Ian Jackson
  2019-08-27 20:47             ` Lars Kurth
       [not found]             ` <D8EFC0B6-0FFC-4288-86EC-FD0A0BB8C3BF@citrix.com-0>
  0 siblings, 2 replies; 19+ messages in thread
From: Ian Jackson @ 2019-08-27 17:33 UTC (permalink / raw)
  To: Lars Kurth
  Cc: George Dunlap, minios-devel, Rich Persaud, committers,
	mirageos-devel, xen-devel, win-pv-devel, Stefano Stabellini

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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [Xen-devel] [RFC] Code of Conduct
  2019-08-16 16:20       ` Lars Kurth
@ 2019-08-26 18:03         ` Lars Kurth
  2019-08-27 17:33           ` Ian Jackson
  0 siblings, 1 reply; 19+ messages in thread
From: Lars Kurth @ 2019-08-26 18:03 UTC (permalink / raw)
  To: Rich Persaud, George Dunlap, Stefano Stabellini
  Cc: minios-devel, xen-devel, win-pv-devel, committers, mirageos-devel

[-- 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 --]

<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:36.0pt;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri",sans-serif;}
p.msonormal0, li.msonormal0, div.msonormal0
	{mso-style-name:msonormal;
	mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	font-size:11.0pt;
	font-family:"Calibri",sans-serif;}
span.EmailStyle19
	{mso-style-type:personal;
	font-family:"Calibri",sans-serif;
	color:windowtext;}
span.EmailStyle20
	{mso-style-type:personal-reply;
	font-family:"Calibri",sans-serif;
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
/* List Definitions */
@list l0
	{mso-list-id:20975627;
	mso-list-type:hybrid;
	mso-list-template-ids:632223890 -731375890 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
	{mso-level-number-format:bullet;
	mso-level-text:;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:Symbol;
	mso-fareast-font-family:Calibri;
	mso-bidi-font-family:"Times New Roman";}
@list l0:level2
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:"Courier New";}
@list l0:level3
	{mso-level-number-format:bullet;
	mso-level-text:;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:Wingdings;}
@list l0:level4
	{mso-level-number-format:bullet;
	mso-level-text:;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:Symbol;}
@list l0:level5
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:"Courier New";}
@list l0:level6
	{mso-level-number-format:bullet;
	mso-level-text:;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:Wingdings;}
@list l0:level7
	{mso-level-number-format:bullet;
	mso-level-text:;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:Symbol;}
@list l0:level8
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:"Courier New";}
@list l0:level9
	{mso-level-number-format:bullet;
	mso-level-text:;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:Wingdings;}
@list l1
	{mso-list-id:1298995732;
	mso-list-template-ids:1506857968;}
@list l1:level1
	{mso-level-number-format:bullet;
	mso-level-text:;
	mso-level-tab-stop:36.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-ansi-font-size:10.0pt;
	font-family:Symbol;}
@list l1:level2
	{mso-level-number-format:bullet;
	mso-level-text:;
	mso-level-tab-stop:72.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-ansi-font-size:10.0pt;
	font-family:Symbol;}
@list l1:level3
	{mso-level-number-format:bullet;
	mso-level-text:;
	mso-level-tab-stop:108.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-ansi-font-size:10.0pt;
	font-family:Symbol;}
@list l1:level4
	{mso-level-number-format:bullet;
	mso-level-text:;
	mso-level-tab-stop:144.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-ansi-font-size:10.0pt;
	font-family:Symbol;}
@list l1:level5
	{mso-level-number-format:bullet;
	mso-level-text:;
	mso-level-tab-stop:180.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-ansi-font-size:10.0pt;
	font-family:Symbol;}
@list l1:level6
	{mso-level-number-format:bullet;
	mso-level-text:;
	mso-level-tab-stop:216.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-ansi-font-size:10.0pt;
	font-family:Symbol;}
@list l1:level7
	{mso-level-number-format:bullet;
	mso-level-text:;
	mso-level-tab-stop:252.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-ansi-font-size:10.0pt;
	font-family:Symbol;}
@list l1:level8
	{mso-level-number-format:bullet;
	mso-level-text:;
	mso-level-tab-stop:288.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-ansi-font-size:10.0pt;
	font-family:Symbol;}
@list l1:level9
	{mso-level-number-format:bullet;
	mso-level-text:;
	mso-level-tab-stop:324.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-ansi-font-size:10.0pt;
	font-family:Symbol;}
@list l2
	{mso-list-id:2032802453;
	mso-list-type:hybrid;
	mso-list-template-ids:-2139557310 67698711 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l2:level1
	{mso-level-number-format:alpha-lower;
	mso-level-text:"%1\)";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l2:level2
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l2:level3
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
@list l2:level4
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l2:level5
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l2:level6
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
@list l2:level7
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l2:level8
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l2:level9
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
--></style>
</head>
<body lang="EN-GB" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">&nbsp;<o:p></o:p></p>
<p class="MsoNormal">&nbsp;<o:p></o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="margin-left:72.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">Rich Persaud &lt;persaur@gmail.com&gt;<br>
<b>Date: </b>Friday, 16 August 2019 at 16:49<br>
<b>To: </b>George Dunlap &lt;George.Dunlap@citrix.com&gt;<br>
<b>Cc: </b>Lars Kurth &lt;lars.kurth@citrix.com&gt;, xen-devel &lt;xen-devel@lists.xenproject.org&gt;, &quot;minios-devel@lists.xenproject.org&quot; &lt;minios-devel@lists.xenproject.org&gt;, &quot;mirageos-devel@lists.xenproject.org&quot; &lt;mirageos-devel@lists.xenproject.org&gt;, &quot;win-pv-devel@lists.xenproject.org&quot;
 &lt;win-pv-devel@lists.xenproject.org&gt;, &quot;committers@xenproject.org&quot; &lt;committers@xenproject.org&gt;<br>
<b>Subject: </b>Re: [Xen-devel] [RFC] Code of Conduct</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:72.0pt">&nbsp;<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt">Snip <o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">&nbsp;<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:72.0pt">Hi George,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:72.0pt">&nbsp;<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:72.0pt">Thanks for the detailed response. &nbsp;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. &nbsp;My comment,
 from&nbsp;<a href="https://lists.gt.net/xen/devel/561686#561686">https://lists.gt.net/xen/devel/561686#561686</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:72.0pt">&nbsp;<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal" style="margin-left:72.0pt">Without getting into the merits of Contributor Covenant, there is value in reusing an &quot;upstream CoC&quot; that has been vetted by many organizations and is being continually tested in the real world. &nbsp;<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:72.0pt"><br>
<br>
<br>
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:72.0pt">Similar to the &quot;macro supply chain&quot; topic: &nbsp;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.
 &nbsp;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.<o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal" style="margin-left:72.0pt">&nbsp;<o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-left:72.0pt">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.<o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-left:72.0pt">&nbsp;<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:72.0pt">Rich<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">&nbsp;<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">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.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">&nbsp;<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">How about the following: <o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:72.0pt;text-indent:-18.0pt;mso-list:l0 level1 lfo3">
<![if !supportLists]><span style="font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]>Make a proposal based on the Contributor Covenant<o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:72.0pt;text-indent:-18.0pt;mso-list:l0 level1 lfo3">
<![if !supportLists]><span style="font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]>Try and address some of the key customizations which I have been trying to make (which George outlined nicely)<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">&nbsp;<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">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<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">&nbsp;<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">We can then compare the output and decide which one to go for<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">&nbsp;<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">Lars<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Thank you for the chat at Security Summit. So, I think we concluded that the direction we are going in is roughly correct.<br>
<br>
In the meantime, I had talked to the LF. There is currently an initiative to provide the following
<o:p></o:p></p>
<ul style="margin-top:0cm" type="disc">
<li class="MsoListParagraph" style="margin-left:0cm;mso-list:l0 level1 lfo3">General advice on how to choose and customize CoCs – almost certainly Contributor Covenant will be on that list
<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0cm;mso-list:l0 level1 lfo3">A template and set of best practices on how to implement enforcement &#43; training around it<o:p></o:p></li></ul>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">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.<br>
My gut feeling is that we are looking at 6-9 months before all of this is resolved. Maybe longer.<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Ultimately, we have 3 options:<o:p></o:p></p>
<ol style="margin-top:0cm" start="1" type="a">
<li class="MsoListParagraph" style="margin-left:0cm;mso-list:l2 level1 lfo4">We wait for the LF and revisit then<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0cm;mso-list:l2 level1 lfo4">We go our own way re customization<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0cm;mso-list:l2 level1 lfo4">We draft our own customizations and bring it up in one of the LF meetings discussing this<o:p></o:p></li></ol>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">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<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">What do people think?<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Regards<o:p></o:p></p>
<p class="MsoNormal">Lars<br>
<br>
<o:p></o:p></p>
</div>
</div>
</body>
</html>

[-- 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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [Xen-devel] [RFC] Code of Conduct
  2019-08-16 15:49     ` Rich Persaud
@ 2019-08-16 16:20       ` Lars Kurth
  2019-08-26 18:03         ` Lars Kurth
  0 siblings, 1 reply; 19+ messages in thread
From: Lars Kurth @ 2019-08-16 16:20 UTC (permalink / raw)
  To: Rich Persaud, George Dunlap
  Cc: minios-devel, xen-devel, win-pv-devel, committers, mirageos-devel

[-- 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 --]

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:36.0pt;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri",sans-serif;}
p.msonormal0, li.msonormal0, div.msonormal0
	{mso-style-name:msonormal;
	mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	font-size:11.0pt;
	font-family:"Calibri",sans-serif;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri",sans-serif;
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
/* List Definitions */
@list l0
	{mso-list-id:20975627;
	mso-list-type:hybrid;
	mso-list-template-ids:632223890 -731375890 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
	{mso-level-number-format:bullet;
	mso-level-text:;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:Symbol;
	mso-fareast-font-family:Calibri;
	mso-bidi-font-family:"Times New Roman";}
@list l0:level2
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:"Courier New";}
@list l0:level3
	{mso-level-number-format:bullet;
	mso-level-text:;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:Wingdings;}
@list l0:level4
	{mso-level-number-format:bullet;
	mso-level-text:;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:Symbol;}
@list l0:level5
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:"Courier New";}
@list l0:level6
	{mso-level-number-format:bullet;
	mso-level-text:;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:Wingdings;}
@list l0:level7
	{mso-level-number-format:bullet;
	mso-level-text:;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:Symbol;}
@list l0:level8
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:"Courier New";}
@list l0:level9
	{mso-level-number-format:bullet;
	mso-level-text:;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:Wingdings;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-GB" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="margin-left:36.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">Rich Persaud &lt;persaur@gmail.com&gt;<br>
<b>Date: </b>Friday, 16 August 2019 at 16:49<br>
<b>To: </b>George Dunlap &lt;George.Dunlap@citrix.com&gt;<br>
<b>Cc: </b>Lars Kurth &lt;lars.kurth@citrix.com&gt;, xen-devel &lt;xen-devel@lists.xenproject.org&gt;, &quot;minios-devel@lists.xenproject.org&quot; &lt;minios-devel@lists.xenproject.org&gt;, &quot;mirageos-devel@lists.xenproject.org&quot; &lt;mirageos-devel@lists.xenproject.org&gt;, &quot;win-pv-devel@lists.xenproject.org&quot;
 &lt;win-pv-devel@lists.xenproject.org&gt;, &quot;committers@xenproject.org&quot; &lt;committers@xenproject.org&gt;<br>
<b>Subject: </b>Re: [Xen-devel] [RFC] Code of Conduct<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class="MsoNormal">Snip <o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt">Hi George,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt">Thanks for the detailed response. &nbsp;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. &nbsp;My comment,
 from&nbsp;<a href="https://lists.gt.net/xen/devel/561686#561686">https://lists.gt.net/xen/devel/561686#561686</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><o:p>&nbsp;</o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt">Without getting into the merits of Contributor Covenant, there is value in reusing an &quot;upstream CoC&quot; that has been vetted by many organizations and is being continually tested in the real world. &nbsp;<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><br>
<br>
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt">Similar to the &quot;macro supply chain&quot; topic: &nbsp;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.
 &nbsp;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.<o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><o:p>&nbsp;</o:p></p>
</div>
<p class="MsoNormal" style="margin-left:36.0pt">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.<o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt">Rich<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">How about the following: <o:p></o:p></p>
<ul style="margin-top:0cm" type="disc">
<li class="MsoListParagraph" style="margin-left:0cm;mso-list:l0 level1 lfo1">Make a proposal based on the Contributor Covenant<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0cm;mso-list:l0 level1 lfo1">Try and address some of the key customizations which I have been trying to make (which George outlined nicely)<o:p></o:p></li></ul>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">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<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">We can then compare the output and decide which one to go for<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Lars<o:p></o:p></p>
</div>
</div>
</body>
</html>

[-- 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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [Xen-devel] [RFC] Code of Conduct
  2019-08-16 11:19   ` George Dunlap
@ 2019-08-16 15:49     ` Rich Persaud
  2019-08-16 16:20       ` Lars Kurth
  0 siblings, 1 reply; 19+ messages in thread
From: Rich Persaud @ 2019-08-16 15:49 UTC (permalink / raw)
  To: George Dunlap
  Cc: Lars Kurth, minios-devel, committers, mirageos-devel, xen-devel,
	win-pv-devel

[-- 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 --]

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

[-- 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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [Xen-devel] [RFC] Code of Conduct
  2019-08-15 17:23 ` Rich Persaud
  2019-08-15 18:01   ` Lars Kurth
@ 2019-08-16 11:19   ` George Dunlap
  2019-08-16 15:49     ` Rich Persaud
  1 sibling, 1 reply; 19+ messages in thread
From: George Dunlap @ 2019-08-16 11:19 UTC (permalink / raw)
  To: Rich Persaud, Lars Kurth
  Cc: minios-devel, xen-devel, win-pv-devel, committers, mirageos-devel

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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [Xen-devel] [RFC] Code of Conduct
  2019-08-15 19:08         ` Rich Persaud
@ 2019-08-15 19:25           ` " Lars Kurth
  0 siblings, 0 replies; 19+ messages in thread
From: Lars Kurth @ 2019-08-15 19:25 UTC (permalink / raw)
  To: Rich Persaud
  Cc: Lars Kurth, minios-devel, committers, mirageos-devel, xen-devel,
	win-pv-devel

[-- 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 --]

<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 15 Aug 2019, at 20:08, Rich Persaud &lt;<a href="mailto:persaur@gmail.com" class="">persaur@gmail.com</a>&gt; wrote:</div><div class=""><div dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">Following the discussion we had at the Developer Summit (see<span class="Apple-converted-space">&nbsp;</span><a href="https://wiki.xenproject.org/wiki/Design_Sessions_2019#Community_Issues_.2F_Improvements_-_Communication.2C_Code_of_Conduct.2C_etc" class="">https://wiki.xenproject.org/wiki/Design_Sessions_2019#Community_Issues_.2F_Improvements_-_Communication.2C_Code_of_Conduct.2C_etc</a>. for notes) I put together a draft for the Code of Conduct which can be found here as well as inlined below</span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""><a href="https://docs.google.com/document/d/1NnWdU_VnC1N_ZzxQG6jU9fnY2GPVCcfPJT5KY61WXJM/edit?usp=sharing" class="">https://docs.google.com/document/d/1NnWdU_VnC1N_ZzxQG6jU9fnY2GPVCcfPJT5KY61WXJM/edit?usp=sharing</a></span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">It is based on the LF Events CoC as we agreed on (the diff is attached). I took the scope and enforcement sections from<span class="Apple-converted-space">&nbsp;</span><a href="https://www.contributor-covenant.org/version/1/4/code-of-conduct.html" class="">https://www.contributor-covenant.org/version/1/4/code-of-conduct.html</a><span class="Apple-converted-space">&nbsp;</span>and simplified it rather than inventing something new.</span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">&nbsp;&nbsp;Is there precedent for applying a legal contract (Code of Conduct) that was designed for physical space (conference event) to an online context? &nbsp;&nbsp;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?</span><br class=""></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">If you look at<span class="Apple-converted-space">&nbsp;</span><a href="https://www.contributor-covenant.org/version/1/4/code-of-conduct.html" class="">https://www.contributor-covenant.org/version/1/4/code-of-conduct.html</a><span class="Apple-converted-space">&nbsp;</span>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”.</span><br class=""></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">Thanks for the pointer, that's exactly what I was hoping to find. &nbsp;Here is some text from Contributor Covenant:</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">"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.</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">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."</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">This is different from the proposed CoC, because:</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">(a) repercussions are not specified, i.e. they can be contextual</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">(b) there is a confidentiality provision</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">(c) decisions are made by open-source project leadership, not a separate "CoC team" with TBD members, electoral process and governance<span class="Apple-converted-space">&nbsp;</span></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">Can Xen Project adopt Contributor Covenant directly? &nbsp;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: &nbsp;<a href="https://www.contributor-covenant.org/adopters" class="">https://www.contributor-covenant.org/adopters</a></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">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</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">See<span class="Apple-converted-space">&nbsp;</span><a href="https://itsfoss.com/linux-code-of-conduct/" class="">https://itsfoss.com/linux-code-of-conduct/</a></span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">I am not sure what the risk would be if we followed Linux</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">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.<span class="Apple-converted-space">&nbsp;</span></span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">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</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">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."</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">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</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">In any case, the Covenant suggested to customise the template to our needs. And that's what I have done.</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">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</span><br class=""></blockquote><span class=""></span><br class=""><span class="">Differences remain, e.g. Contributor Covenant has a whitelist and blacklist of acceptable behaviors, the proposed Xen CoC only has a blacklist. &nbsp;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.</span></div></div></blockquote><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">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. &nbsp;</div><div dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><br class=""></div><div dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">Similar to the "macro supply chain" topic: &nbsp;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. &nbsp;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.</div></div></blockquote><div><br class=""></div><div>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</div><div><br class=""></div><div>I think all of your concerns can be addressed either way by modifying the proposal or modifying the covenant</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><span class=""></span><span class="">Are there upstream examples of electoral governance for "CoC teams", or would we need to develop that from scratch? &nbsp;</span></div></div></blockquote><div><br class=""></div><div>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</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><span class="">Xen Summit design session notes say:&nbsp;</span></div><div dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">"<span style="background-color: rgba(255, 255, 255, 0);" class="">An area for discussion which was not quite agreed upon pending an initial proposal was how we would approach the handling of issues</span></div><div dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><ul style="list-style-type: square; margin: 0.3em 0px 0px 1.6em; padding: 0px; list-style-image: url(&quot;data:image/svg+xml,%3Csvg xmlns=%22http://www.w3.org/2000/svg%22 width=%225%22 height=%2213%22 viewBox=%220 0 1.323 3.44%22%3E %3Cpath fill=%22%23638c9c%22 d=%22M0 1.852v1.323h1.323V1.852z%22/%3E %3C/svg%3E&quot;);" class=""><li style="margin-bottom: 0.1em;" class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">A committee</span></li><li style="margin-bottom: 0.1em;" class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">Probably 2-3 people of different backgrounds maybe from different subprojects"</span></li></ul><div class=""><br class=""></div><div class="">Could we also include existing Xen project leadership in the CoC team? &nbsp;How would selection of people for a CoC team differ from the existing process for selecting committers, etc?</div></div></div></blockquote></div><div><br class=""></div><div>I was actually thinking that the CoC team would be made up of members of</div><div>* Xen project leadership from different sub-projects (not just the Hypervisor committers).&nbsp;</div><div>&nbsp; Rationale: the CoC is project wide, not specific to xen-devel@</div><div>&nbsp; And we have some leadership team members which do not want to have to deal with CoC issues</div><div>* Advisory Board members (if one wanted to volunteer)&nbsp;</div><div>* 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</div><div><br class=""></div><div>In any case: I think I need to hear more different views</div><div><br class=""></div><div>Lars</div><div><br class=""></div><div><br class=""></div><br class=""></body></html>

[-- 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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [Xen-devel] [RFC] Code of Conduct
  2019-08-15 18:01   ` Lars Kurth
@ 2019-08-15 18:27     ` Rich Persaud
  2019-08-15 18:46       ` [Xen-devel] [win-pv-devel] " Lars Kurth
  0 siblings, 1 reply; 19+ messages in thread
From: Rich Persaud @ 2019-08-15 18:27 UTC (permalink / raw)
  To: Lars Kurth
  Cc: minios-devel, xen-devel, win-pv-devel, committers, mirageos-devel

[-- 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 --]

<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"></div><div dir="ltr">On Aug 15, 2019, at 14:01, Lars Kurth &lt;<a href="mailto:lars.kurth@citrix.com">lars.kurth@citrix.com</a>&gt; wrote:</div><div dir="ltr"><br></div><blockquote type="cite"><div dir="ltr">

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:-webkit-standard;
	panose-1:2 11 6 4 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:#0563C1;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:#954F72;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri",sans-serif;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:"Calibri",sans-serif;}
span.apple-converted-space
	{mso-style-name:apple-converted-space;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
/* List Definitions */
@list l0
	{mso-list-id:1558200443;
	mso-list-type:hybrid;
	mso-list-template-ids:386465514 67698711 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
	{mso-level-number-format:alpha-lower;
	mso-level-text:"%1\)";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	color:windowtext;}
@list l0:level2
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level3
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
@list l0:level4
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level5
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level6
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
@list l0:level7
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level8
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level9
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
--></style>


<div class="WordSection1">
<p class="MsoPlainText">Hi Rich,<o:p></o:p></p>
<p class="MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class="MsoPlainText">thanks for the feedback. I am going to <o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><o:p>&nbsp;</o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">On 15/08/2019, 18:23, "Rich Persaud" &lt;<a href="mailto:persaur@gmail.com">persaur@gmail.com</a>&gt; wrote:<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><o:p>&nbsp;</o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp; &gt; On Aug 9, 2019, at 13:48, Lars Kurth &lt;<a href="mailto:lars.kurth@citrix.com">lars.kurth@citrix.com</a>&gt; wrote:<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp; &gt; <o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&gt; Hi all,<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp; <o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp;&nbsp;Hi Lars,<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp; <o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&gt; <o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&gt; Following the discussion we had at the Developer Summit (see <a href="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</a>. for notes)
 I put together a draft for the Code of Conduct which can be found here as well as inlined below<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp; &gt; <a href="https://docs.google.com/document/d/1NnWdU_VnC1N_ZzxQG6jU9fnY2GPVCcfPJT5KY61WXJM/edit?usp=sharing">https://docs.google.com/document/d/1NnWdU_VnC1N_ZzxQG6jU9fnY2GPVCcfPJT5KY61WXJM/edit?usp=sharing</a>
<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&gt; <o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&gt; It is based on the LF Events CoC as we agreed on (the diff is attached). I took the scope and enforcement sections from <a href="https://www.contributor-covenant.org/version/1/4/code-of-conduct.html">https://www.contributor-covenant.org/version/1/4/code-of-conduct.html</a> and simplified
 it rather than inventing something new.<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp; <o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp;&nbsp;Is there precedent for applying a legal contract (Code of Conduct) that was designed for physical space (conference event) to an online context?&nbsp;&nbsp; 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?<o:p></o:p></p>
<p class="MsoPlainText"><span style="color:black"><o:p>&nbsp;</o:p></span></p>
<p class="MsoPlainText"><span style="color:black">If you look at </span><a href="https://www.contributor-covenant.org/version/1/4/code-of-conduct.html">https://www.contributor-covenant.org/version/1/4/code-of-conduct.html</a> 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”.</p></div></div></blockquote><div><br></div><div>Thanks for the pointer, that's exactly what I was hoping to find. &nbsp;Here is some text from Contributor Covenant:</div><div><div><br></div><div>"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.</div><div>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."</div><div><br></div><div>This is different from the proposed CoC, because:</div><div><br></div><div>&nbsp; (a) repercussions are not specified, i.e. they can be contextual</div><div>&nbsp; (b) there is a confidentiality provision</div><div>&nbsp; (c) decisions are made by open-source project leadership, not a separate "CoC team" with TBD members, electoral process and governance&nbsp;</div><div><br></div><div>Can Xen Project adopt Contributor Covenant directly? &nbsp;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: &nbsp;<a href="https://www.contributor-covenant.org/adopters">https://www.contributor-covenant.org/adopters</a></div><div><br></div><div>Rich</div></div><blockquote type="cite"><div dir="ltr"><div class="WordSection1">
</div>


</div></blockquote></body></html>

[-- 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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [Xen-devel] [RFC] Code of Conduct
  2019-08-15 17:23 ` Rich Persaud
@ 2019-08-15 18:01   ` Lars Kurth
  2019-08-15 18:27     ` Rich Persaud
  2019-08-16 11:19   ` George Dunlap
  1 sibling, 1 reply; 19+ messages in thread
From: Lars Kurth @ 2019-08-15 18:01 UTC (permalink / raw)
  To: Rich Persaud
  Cc: minios-devel, xen-devel, win-pv-devel, committers, mirageos-devel

[-- 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 --]

<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:-webkit-standard;
	panose-1:2 11 6 4 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:#0563C1;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:#954F72;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri",sans-serif;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:"Calibri",sans-serif;}
span.apple-converted-space
	{mso-style-name:apple-converted-space;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
/* List Definitions */
@list l0
	{mso-list-id:1558200443;
	mso-list-type:hybrid;
	mso-list-template-ids:386465514 67698711 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
	{mso-level-number-format:alpha-lower;
	mso-level-text:"%1\)";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	color:windowtext;}
@list l0:level2
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level3
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
@list l0:level4
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level5
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level6
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
@list l0:level7
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level8
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level9
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
--></style>
</head>
<body lang="EN-GB" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoPlainText">Hi Rich,<o:p></o:p></p>
<p class="MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class="MsoPlainText">thanks for the feedback. I am going to <o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><o:p>&nbsp;</o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">On 15/08/2019, 18:23, &quot;Rich Persaud&quot; &lt;persaur@gmail.com&gt; wrote:<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><o:p>&nbsp;</o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp; &gt; On Aug 9, 2019, at 13:48, Lars Kurth &lt;lars.kurth@citrix.com&gt; wrote:<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp; &gt; <o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&gt; Hi all,<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp; <o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp;&nbsp;Hi Lars,<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp; <o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&gt; <o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&gt; 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<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp; &gt; https://docs.google.com/document/d/1NnWdU_VnC1N_ZzxQG6jU9fnY2GPVCcfPJT5KY61WXJM/edit?usp=sharing
<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&gt; <o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&gt; 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.<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp; <o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp;&nbsp;Is there precedent for applying a legal contract (Code of Conduct) that was designed for physical space (conference event) to an online context?&nbsp;&nbsp; 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?<o:p></o:p></p>
<p class="MsoPlainText"><span style="color:black"><o:p>&nbsp;</o:p></span></p>
<p class="MsoPlainText"><span style="color:black">If you look at </span>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”.<o:p></o:p></p>
<p class="MsoPlainText"><br>
<span style="color:black">Also of course, the Code of Conduct is not a legal or legally enforceable document<o:p></o:p></span></p>
<p class="MsoPlainText">&nbsp;&nbsp;&nbsp; <o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&gt; # Expected Behavior<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp; &gt; All Xen Project community members are expected to behave in accordance with
<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&gt; professional standards, with both the Xen Project Code of Conduct as well as their
<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&gt; respective employer’s policies governing appropriate workplace behavior, and
<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&gt; applicable laws.<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp; <o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp;&nbsp;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.&nbsp;&nbsp; In this current draft, we have a single
 sentence on positive behavior, with inclusion-by-reference to:<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp; <o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp;&nbsp;- professional standards<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp; - corporate policy<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp; - city, state and national/federal law<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp; <o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp;&nbsp;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?<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp; <o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp;&nbsp;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?&nbsp; Within Xen source code, we have been moving away from blacklists towards whitelists.<o:p></o:p></p>
<p class="MsoPlainText">&nbsp;&nbsp;&nbsp; <o:p></o:p></p>
<p class="MsoNormal">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. &nbsp;<span style="font-family:&quot;-webkit-standard&quot;,serif;color:black"><o:p></o:p></span></p>
<p class="MsoPlainText"><span style="color:black"><o:p>&nbsp;</o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp; &gt; # Unacceptable Behavior<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp; &gt; Harassment will not be tolerated in the Xen Project Community in any form,
<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&gt; including but not limited to harassment based on gender, gender identity and
<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&gt; expression, sexual orientation, disability, physical appearance, body size, race,
<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&gt; age, religion, ethnicity, nationality, level of experience, education, or
<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&gt; socio-economic status or any other status protected by laws in jurisdictions in
<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&gt; which community members are based. Harassment includes the use of abusive,
<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&gt; offensive or degrading language, intimidation, stalking, harassing photography
<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&gt; or recording, inappropriate physical contact, sexual imagery and unwelcome
<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&gt; sexual advances, requests for sexual favors, publishing others' private
<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&gt; information such as a physical or electronic address without explicit permission<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp; <o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp;&nbsp;Picking one item at random:&nbsp; would a conference-originated blacklist prohibition be appropriate for online open-source development?&nbsp; 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?&nbsp; That could disqualify much of the current development community.<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp; <o:p></o:p></p>
<p class="MsoPlainText">Again, the list is very similar to those in most other CoC’s. So, I think the answer is yes<o:p></o:p></p>
<p class="MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp; &gt; Any report of harassment within the Xen Project community will be addressed
<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&gt; swiftly. Participants asked to stop any harassing behavior are expected to
<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&gt; comply immediately. Anyone who witnesses or is subjected to unacceptable
<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&gt; behavior should notify the Xen Project’s CoC team via conduct@xenproject.org.<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp; &gt; <o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&gt; # Consequences of Unacceptable Behavior<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp; &gt; If a participant engages in harassing behavior, the Xen Project’s CoC team may
<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&gt; take any action it deems appropriate, ranging from issuance of a warning to the
<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&gt; offending individual to expulsion from the Xen Project community.<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp; <o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp;&nbsp;This is an enforceable action in the physical world, e.g. conference event, but may be more difficult online.&nbsp; 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.&nbsp;&nbsp; It may be better to look for precedent CoC legal clauses that were designed for online contexts.<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp; <o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp;&nbsp;Let's assume that digital identity can be proven and a person can be expelled from the Xen Project community.&nbsp; Would this action apply only to the person's digital identity at Company X, or also to their
 new digital identity at Company Y?&nbsp; i.e. would behavior and enforcement be scoped to the individual, the company or both?&nbsp;
<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp;&nbsp;<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp;&nbsp;The &quot;Acceptable Behavior&quot; clause includes individual, company and nation-state in scope of governance.&nbsp; If the &quot;Unacceptable Behavior&quot; clauses would lead to economic harm for a company, e.g. impacting a
 company's ability to ship a commercial release of&nbsp; 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?&nbsp; What would be due process for such improvement opportunity, in compliance with nation-state labor laws for employee termination?<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp; <o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp;&nbsp;If the &quot;Unacceptable Behavior&quot; 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?&nbsp; If so, would such a public employment blacklist be compliant with the labor laws of affected nation-states?&nbsp;
<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp;&nbsp;<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp;&nbsp;Would Xen-contributing companies be required to enforce the blacklist when hiring employees?&nbsp; If so, would this create the appearance of a &quot;cartel&quot;, a construct prohibited by some nation-states under antitrust
 law.&nbsp; 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?<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp; <o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp;&nbsp;Would these considerations influence a company which is selecting a global labor pool of hypervisor talent and open-source hypervisor for their commercial product?&nbsp; Can we perform a comparative analysis
 of these scenarios for the proposed Xen Project CoC vs. other OSS hypervisors which compete with Xen?<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp; <o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">&nbsp;&nbsp;&nbsp;&nbsp;These are some example scenarios where a conference/event CoC may not be suitable.<o:p></o:p></p>
<p class="MsoPlainText"><span style="color:black"><o:p>&nbsp;</o:p></span></p>
<p class="MsoPlainText"><span style="color:black">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. &nbsp;However, in this case (and probably most cases) that I would also violate my
</span>employer’s policies governing appropriate workplace and could lose my job if the victim reported the issue to my employer.
<span style="color:black"><o:p></o:p></span></p>
<p class="MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class="MsoPlainText">The challenge for the project would be to communicate why a community member was expelled. In such a scenario:<o:p></o:p></p>
<ol style="margin-top:0cm" start="1" type="a">
<li class="MsoPlainText" style="color:black;mso-list:l0 level1 lfo1"><span style="color:windowtext">If we stay opaque there may be community pushback
</span><o:p></o:p></li><li class="MsoPlainText" style="color:black;mso-list:l0 level1 lfo1"><span style="color:windowtext">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</span><br>
<br>
<o:p></o:p></li></ol>
<p class="MsoPlainText"><span style="color:black">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.<o:p></o:p></span></p>
<p class="MsoPlainText"><span style="color:black"><o:p>&nbsp;</o:p></span></p>
<p class="MsoPlainText"><span style="color:black">There are very few examples of how projects would indeed handle violations. A good example is Django: see<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">* </span><a href="https://www.djangoproject.com/conduct/enforcement-manual/"><span style="color:blue">https://www.djangoproject.com/conduct/enforcement-manual/</span></a>
<o:p></o:p></p>
<p class="MsoNormal"><span style="color:black">* </span><a href="https://www.djangoproject.com/conduct/reporting/">https://www.djangoproject.com/conduct/reporting/</a><o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Best Regards<o:p></o:p></p>
<p class="MsoNormal">Lars<o:p></o:p></p>
<p class="MsoPlainText"><span style="color:black"><o:p>&nbsp;</o:p></span></p>
<p class="MsoPlainText"><span style="color:black"><o:p>&nbsp;</o:p></span></p>
<p class="MsoPlainText"><span style="color:black"><o:p>&nbsp;</o:p></span></p>
<p class="MsoPlainText">&nbsp;&nbsp;&nbsp; <o:p></o:p></p>
<p class="MsoPlainText"><o:p>&nbsp;</o:p></p>
</div>
</body>
</html>

[-- 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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [Xen-devel] [RFC] Code of Conduct
  2019-08-09 17:48 Lars Kurth
@ 2019-08-15 17:23 ` Rich Persaud
  2019-08-15 18:01   ` Lars Kurth
  2019-08-16 11:19   ` George Dunlap
  0 siblings, 2 replies; 19+ messages in thread
From: Rich Persaud @ 2019-08-15 17:23 UTC (permalink / raw)
  To: Lars Kurth
  Cc: minios-devel, xen-devel, win-pv-devel, committers, mirageos-devel

> 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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* [Xen-devel] [RFC] Code of Conduct
@ 2019-08-09 17:48 Lars Kurth
  2019-08-15 17:23 ` Rich Persaud
  0 siblings, 1 reply; 19+ messages in thread
From: Lars Kurth @ 2019-08-09 17:48 UTC (permalink / raw)
  To: xen-devel, minios-devel, mirageos-devel, win-pv-devel; +Cc: committers

[-- 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

^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, back to index

Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <AB34D39A-A120-440E-9309-3950E7A465A5@citrix.com-0>
2019-08-12 11:35 ` [Xen-devel] [RFC] Code of Conduct George Dunlap
2019-08-12 14:27   ` Lars Kurth
2019-08-12 14:35     ` George Dunlap
2019-08-13 14:30       ` Lars Kurth
2019-08-09 17:48 Lars Kurth
2019-08-15 17:23 ` Rich Persaud
2019-08-15 18:01   ` Lars Kurth
2019-08-15 18:27     ` Rich Persaud
2019-08-15 18:46       ` [Xen-devel] [win-pv-devel] " Lars Kurth
2019-08-15 19:08         ` Rich Persaud
2019-08-15 19:25           ` [Xen-devel] " Lars Kurth
2019-08-16 11:19   ` George Dunlap
2019-08-16 15:49     ` Rich Persaud
2019-08-16 16:20       ` Lars Kurth
2019-08-26 18:03         ` Lars Kurth
2019-08-27 17:33           ` Ian Jackson
2019-08-27 20:47             ` Lars Kurth
2019-08-28  0:53               ` Stefano Stabellini
2019-08-28  2:02                 ` Lars Kurth
     [not found]             ` <D8EFC0B6-0FFC-4288-86EC-FD0A0BB8C3BF@citrix.com-0>
2019-09-02 15:48               ` Ian Jackson
2019-09-02 18:10                 ` Lars Kurth

Xen-Devel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/xen-devel/0 xen-devel/git/0.git
	git clone --mirror https://lore.kernel.org/xen-devel/1 xen-devel/git/1.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 xen-devel xen-devel/ https://lore.kernel.org/xen-devel \
		xen-devel@lists.xenproject.org xen-devel@archiver.kernel.org
	public-inbox-index xen-devel


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.xenproject.lists.xen-devel


AGPL code for this site: git clone https://public-inbox.org/ public-inbox