qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: "Thomas Huth" <thuth@redhat.com>,
	"Daniel P. Berrangé" <berrange@redhat.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
	qemu-devel <qemu-devel@nongnu.org>,
	"Alexander Graf" <agraf@csgraf.de>,
	"Stefan Hajnoczi" <stefanha@redhat.com>,
	"Alex Bennée" <alex.bennee@linaro.org>,
	"Andreas Färber" <afaerber@suse.de>
Subject: Re: [PATCH] docs: Add a QEMU Code of Conduct and Conflict Resolution Policy document
Date: Tue, 30 Mar 2021 11:59:07 +0200	[thread overview]
Message-ID: <538be5a1-4396-71eb-30ff-1501040190f7@redhat.com> (raw)
In-Reply-To: <0d20369b-1f2e-1ac6-fb7e-556453ce5666@redhat.com>

On 30/03/21 09:13, Thomas Huth wrote:
> Contributor Covenant 1.x is certainly an option, too, but it has IMHO 
> already quite rigorous language ("Project maintainers have the [...] 
> responsibility to remove, edit, or reject comments, commits, code, wiki 
> edits ...", "Project maintainers who do not [...] enforce the Code of 
> Conduct may be permanently removed from the project team."), which could 
> either scare away people from taking maintainers responsibility or also 
> could be used fire up arguments ("you are a maintainer, now according to 
> the CoC you have to do this and that..."), which I'd rather like to avoid.
> (well, as you know, I'm not a native English speaker, so I might also 
> have gotten that tone wrong, but that's the impression that I had after 
> reading that text as non-native speaker).

I see your point.  We also have the issue that mailing list archives are 
basically immutable and maintained on Savannah.  It would be hard for 
anyone to remove problematic language in many cases.

My first review last night focused on the conflict resolution policy 
because I was obviously more familiar with it.  I have now reread the 
code of conduct more closely and I like it, both the original and the 
small changes you made to the Django code of conduct.

I do have a couple remarks:

* like its ancestor, it is still erring on the opposite side by not 
identifying who is responsible for having a welcoming community, which 
goes beyond remediation.  Maintainers do have _some_ responsibility in 
that respect, and it should be mentioned somewhere.

* this sentence could be seen as making QEMU responsible for acting 
based on what people say on Facebook or Twitter:

> In addition, violations of this code outside these spaces may
> +affect a person's ability to participate within them.

I don't want to open that can of worms; not now at least.  The conflict 
resolution policy already calls out specific exceptions as a consequence 
of CoC violations, and I think that's enough.

As you're the one doing the work I don't want to impose my view, but I'd 
like to ask you to consider at least the following two changes:

* replace the above sentence with "This code of conduct also applies 
outside these spaces, when an individual acts as a representative or a 
member of the project or its community".

* in the paragraph after it ("If you believe someone is violating the 
code of conduct...") prepend the following text from the Contributor 
Covenant: "By adopting this Code of Conduct, project maintainers commit 
themselves to fairly and consistently applying these principles to every 
aspect of managing this project".

(On top of this the "When we disagree, try to understand why" bullet is 
somewhat redundant with both the conflict resolution policy and other 
parts of the code of conduct, and I like such documents to be as short 
as possible.  But that's more cosmetic than normative, so it's not a big 
deal).

What do you think?

Thanks,

Paolo



  reply	other threads:[~2021-03-30 10:00 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-29 18:01 [PATCH] docs: Add a QEMU Code of Conduct and Conflict Resolution Policy document Thomas Huth
2021-03-29 18:33 ` Daniel P. Berrangé
2021-03-29 20:59   ` Paolo Bonzini
2021-03-30  7:13     ` Thomas Huth
2021-03-30  9:59       ` Paolo Bonzini [this message]
2021-03-30  8:18     ` Daniel P. Berrangé
2021-03-31 15:05 Paolo Bonzini
2021-03-31 15:47 ` Thomas Huth
2021-03-31 16:11   ` Paolo Bonzini
2021-03-31 17:01 ` David Edmondson
2021-03-31 19:12 ` Alex Bennée
2021-04-07 10:23 ` Kevin Wolf
2021-04-07 13:35   ` Alex Bennée
2021-04-07 15:42     ` Kevin Wolf
2021-04-07 16:03       ` Daniel P. Berrangé
2021-04-10  6:29         ` Thomas Huth
2021-04-13  7:42       ` Paolo Bonzini
2021-04-13 10:23         ` Andreas Färber
2021-04-13 10:24           ` Peter Maydell
2021-04-13 11:41             ` Markus Armbruster
2021-04-13 16:25 ` Daniel P. Berrangé
2021-04-13 21:16   ` Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=538be5a1-4396-71eb-30ff-1501040190f7@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=afaerber@suse.de \
    --cc=agraf@csgraf.de \
    --cc=alex.bennee@linaro.org \
    --cc=berrange@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).