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 exp
Re: [MirageOS-devel] [Xen-devel] [RFC] Code of Conduct
> 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? > 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 . > > # 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
Re: [MirageOS-devel] [Xen-devel] [RFC] Code of Conduct
On Aug 15, 2019, at 14:01, Lars Kurth wrote: > > Hi Rich, > > thanks for the feedback. I am going to > > On 15/08/2019, 18:23, "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? > > 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 ___ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/mirageos-devel
Re: [MirageOS-devel] [win-pv-devel] [Xen-devel] [RFC] Code of Conduct
> On Aug 15, 2019, at 14:46, Lars Kurth wrote: >> On 15 Aug 2019, at 19:27, Rich Persaud wrote: >> On Aug 15, 2019, at 14:01, Lars Kurth wrote: >> >>> Hi Rich, >>> >>> thanks for the feedback. I am going to >>> >>> On 15/08/2019, 18:23, "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? >>> >>> If you look at >>> https://www.contributor-covenant.org/version/1/4/code-of-conduct.html or >>> many other examples, what we ended up with is almost identical. The same is >>> true for most other CoCs which are used as “gold standard”. >> >> Thanks for the pointer, that's exactly what I was hoping to find. Here is >> some text from Contributor Covenant: >> >> "Instances of abusive, harassing, or otherwise unacceptable behavior may be >> reported by contacting the project team at [INSERT EMAIL ADDRESS]. All >> complaints will be reviewed and investigated and will result in a response >> that is deemed necessary and appropriate to the circumstances. The project >> team is obligated to maintain confidentiality with regard to the reporter of >> an incident. Further details of specific enforcement policies may be posted >> separately. >> Project maintainers who do not follow or enforce the Code of Conduct in good >> faith may face temporary or permanent repercussions as determined by other >> members of the project’s leadership." >> >> This is different from the proposed CoC, because: >> >> (a) repercussions are not specified, i.e. they can be contextual >> (b) there is a confidentiality provision >> (c) decisions are made by open-source project leadership, not a separate >> "CoC team" with TBD members, electoral process and governance >> >> Can Xen Project adopt Contributor Covenant directly? It has a large base of >> adopters, including Intel and Google projects, so we would benefit from >> upstream improvements as the CoC is tested in the real world: >> https://www.contributor-covenant.org/adopters > > We most definitely could and I am open to the idea. However, when Linux > adopted it, there was significant controversy because of the origin of the > Contributor Covenant > > See https://itsfoss.com/linux-code-of-conduct/ > > I am not sure what the risk would be if we followed Linux > > However, we can address all of the above with what we have: The section you > quoted was indeed from the covenant (see attribution) and I simply modified > it based on the discussion we had at the summit. > > > a) We could leave the repercussion section out - I think it is clearer to > have one, but we can clearly debate the pros and cons of not having one > b) There is a confidentiality provision: "The Xen Project’s CoC team is > obligated to maintain confidentiality with regard to the reporter of an > incident." > c) In the design session at the summit the present project leadership team > members felt we should have a CoC team, which is why I changed it > > In any case, the Covenant suggested to customise the template to our needs. > And that's what I have done. > > It was also interesting that when I started with the LF events CoC, I still > ended up with something very similar to most of the other CoCs out there Differenc
Re: [MirageOS-devel] [Xen-devel] [PATCH v2 4/6] Add Code Review Guide
On Nov 28, 2019, at 05:12, Jan Beulich wrote: > > On 28.11.2019 01:54, Stefano Stabellini wrote: >>> On Thu, 26 Sep 2019, Lars Kurth wrote: >>> From: Lars Kurth >>> >>> This document highlights what reviewers such as maintainers and committers >>> look >>> for when reviewing code. It sets expectations for code authors and provides >>> a framework for code reviewers. >> >> I think the document is missing a couple of things: >> >> - a simple one line statement that possibly the most important thing in >> a code review is to indentify any bugs in the code >> >> - an explanation that requests for major changes to the series should be >> made early on (i.e. let's not change the architecture of a feature at >> v9 if possible) I also made this comment in reply to patch #5. I'll >> let you decide where is the best place for it. > > This needs balancing. People crucial to the evaluation of a new > feature and its implementation simply may not have the time to > reply prior to v9. We've had situations where people posted new > revisions every other day, sometimes even more than one per day. > > As indicated in several other contexts before - imo people not > helping to shoulder the review load should also not have the > expectation that their (large) contributions will be looked at > in due course. To make this actionable, we could have: - reviewer demand index: automated index of open patches still in need of review, sorted by decreasing age - review flow control: each new patch submission cites one recent review by the patch submitter, for a patch of comparable size - reviewer supply growth: a bootstrapping guide for new reviewers and submitters, with patterns, anti-patterns, and examples to be emulated Rich ___ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/mirageos-devel
Re: [MirageOS-devel] [PATCH v2 4/6] Add Code Review Guide
On Nov 28, 2019, at 09:05, Lars Kurth wrote: > > On 28/11/2019, 07:37, "Jan Beulich" wrote: > >>On 28.11.2019 14:06, Lars Kurth wrote: >> I can certainly add something on the timing , along the lines of >> * For complex series, consider the time it takes to do reviews (maybe with a >> guide of LOC per hour) and give reviewers enough time to >> * For series with design issues or large questions, try and highlight the >> key open issues in cover letters clearly and solicit feedback from key >> maintainers who can comment on the open issue. The idea is to save both the >> contributor and the reviewers time by focussing on what needs to be resolved >> * Don’t repost a series, unless all review comments are addressed >> or the reviewers asked you to do so. The problem with this is that >> this is somewhat in conflict with the "let's focus on the core >> issues and not get distracted by details early on in a review cycle". >> In other words, this can only work, if reviewers focus on major >> issues in early reviews only and do not focus on style, coding >> standards, etc. > >But this doesn't make much sense either, because then full re-reviews >need to happen anyway on later versions, to also deal with the minor >issues. For RFC kind of series omitting style and alike feedback >certainly makes sense, but as soon as a patch is non-RFC, it should >be considered good to go in by the submitter. > > OK, I think we have a disconnect between ideal and reality. > > I see two issues today > * Key maintainers don't always review RFC series [they end up at the bottom > of the priority list, even though spending time on RFCs will save time > elsewhere later]. So the effect is that then the contributor assumes there > are no major issues and ends it as a proper series > * In practice what has happened often in the past is that design, > architecture, assumption flaws are found in early versions of a series. > - This usually happens because of an oversight or because there was no > design discussion prior to the series being posted and agreed > - Common sense would dictate that the biggest benefit for both the > reviewer, the contributor and the community as a whole would be to try and > focus on such flaws and leave everything aside > - Of course there may be value in doing a detailed reviews of such a series > as there may be bits that are unaffected by such a flaw > - But there will likely be parts which are not: doing a detailed review of > such portions wastes everyone's time > > So coming back to your point. Ideally, it would be nice if we had the > capability to call out parts of a series as "problematic" and treating such > parts differently. We may be able to reuse some "Shift Left" terminology, including citations of previous Xen code reviews to illustrate categories of design issues that can be shifted left: https://devopedia.org/shift-left Rich ___ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/mirageos-devel
