Re: [MirageOS-devel] [Xen-devel] [RFC] Code of Conduct
From: Rich Persaud Date: Friday, 16 August 2019 at 16:49 To: George Dunlap Cc: Lars Kurth , xen-devel , "minios-de...@lists.xenproject.org" , "mirageos-devel@lists.xenproject.org" , "win-pv-de...@lists.xenproject.org" , "committ...@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 ___ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/mirageos-devel
Re: [MirageOS-devel] [Xen-devel] [RFC] Code of Conduct
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 >>> permis
Re: [MirageOS-devel] [Xen-devel] [RFC] Code of Conduct
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 thr
