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

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 8/15/19 6:23 PM, Rich Persaud wrote:
>> On Aug 9, 2019, at 13:48, Lars Kurth <lars.kurth@xxxxxxxxxx> wrote:
>>
>> Hi all,
> 
> Hi Lars,
> 
>>
>> Following the discussion we had at the Developer Summit (see 
>> https://wiki.xenproject.org/wiki/Design_Sessions_2019#Community_Issues_.2F_Improvements_-_Communication.2C_Code_of_Conduct.2C_etc.
>>  for notes) I put together a draft for the Code of Conduct which can be 
>> found here as well as inlined below
>> https://docs.google.com/document/d/1NnWdU_VnC1N_ZzxQG6jU9fnY2GPVCcfPJT5KY61WXJM/edit?usp=sharing
>>  
>>
>> It is based on the LF Events CoC as we agreed on (the diff is attached). I 
>> took the scope and enforcement sections from 
>> https://www.contributor-covenant.org/version/1/4/code-of-conduct.html and 
>> simplified it rather than inventing something new.
> 
> Is there precedent for applying a legal contract (Code of Conduct) that was 
> designed for physical space (conference event) to an online context?   Is 
> there an existing Code of Conduct that was legally designed for a similar, 
> online open-source community context, e.g. operating system or hypervisor or 
> other systems-level software dev?

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@xxxxxxxxxxxxxx.
>>
>> # 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

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/mirageos-devel