On Aug 16, 2019, at 07:19, George Dunlap wrote: > > On 8/15/19 6:23 PM, Rich Persaud wrote: >>> On Aug 9, 2019, at 13:48, Lars Kurth 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