[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On 27/08/2019, 17:54, "Stefano Stabellini" <sstabellini@xxxxxxxxxx> wrote:

    On Tue, 27 Aug 2019, Lars Kurth wrote:
    > On 27/08/2019, 10:33, "Ian Jackson" <ian.jackson@xxxxxxxxxx> 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 

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@xxxxxxxxxxxxxx 
*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 
 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    


MirageOS-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.