[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [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 original. 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 https://www.slideshare.net/xen_com_mgr/xpdds19-keynote-patch-review-for-nonmaintainers-george-dunlap-citrix-systems-uk-ltd 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 Regards Lars _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |