qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Huth <thuth@redhat.com>
To: "Paolo Bonzini" <pbonzini@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 09:13:56 +0200	[thread overview]
Message-ID: <0d20369b-1f2e-1ac6-fb7e-556453ce5666@redhat.com> (raw)
In-Reply-To: <CABgObfbyDTNyww5QE-tOsBVfkZVziX3uwGJCN+7mrXOQ_ZuHFg@mail.gmail.com>

On 29/03/2021 22.59, Paolo Bonzini wrote:
> 
> 
> Il lun 29 mar 2021, 20:33 Daniel P. Berrangé <berrange@redhat.com 
> <mailto:berrange@redhat.com>> ha scritto:
> 
>     The obvious alternative is to import the contributor covenant
> 
>     https://www.contributor-covenant.org/
>     <https://www.contributor-covenant.org/>
> 
> 
> The Contributor Covenant 1.x and 2.x are very different in that 2.x also 
> includes conflict resolution. Unlike the code of conduct, the consequences 
> of bad behavior are hard to generalize across multiple projects, so I would 
> prefer anyway the 1.x version. The differences with the Django CoC aren't 
> substantial.

Right. I also think we should use a code of conduct that allows us to keep 
the conflict resolution in a separate document.

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).

That's why I'd rather prefer the Django CoC instead.

> However this does mean being more careful about the language in the "custom" 
> documents such as the conflict resolution policy.
> 
> 
>     The second, it isn't a static document. It is being evolved over
>     time with new versions issued as understanding of problematic
>     situations evolves. We can choose to periodically update to stay
>     current with the broadly accepted norms.
> 
> 
> This however has the same issues as the "or later" clause of the GPL (see 
> the above example of 1.x vs 2.x for the Contributor Covenant). I don't think 
> upgrade of the CoC should be automatic since there are no "compatibility" 
> issues.

Agreed. We shouldn't auto-upgrade to a newer version of a CoC without 
reviewing the new clauses.

>      > +If you are experiencing conflict, you should first address the perceived
>      > +conflict directly with other involved parties, preferably through a
>      > +real-time medium such as IRC. If this fails,
> 
> 
> I agree with Daniel that this part should only be advisory. For example:
> 
> If you are experiencing conflict, please consider first addressing the 
> perceived  conflict directly with other involved parties, preferably through 
> a real-time medium such as IRC. If this fails or if you do not feel 
> comfortable proceeding this way,...
> 
>     Also this document doesn't mention anything about ensuring the
>     confidentiality/privacy for any complaints reported, which I
>     think is important to state explicitly.
> 
> 
> Agreed, and also the part about keeping a record should be removed from the 
> consequences part because it's a privacy regulation minefield.

Ok, thanks for the feedback, I'll try to incorporate it and send a v2.

  Thomas



  reply	other threads:[~2021-03-30  7:15 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 [this message]
2021-03-30  9:59       ` Paolo Bonzini
2021-03-30  8:18     ` Daniel P. Berrangé
  -- strict thread matches above, loose matches on Subject: below --
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=0d20369b-1f2e-1ac6-fb7e-556453ce5666@redhat.com \
    --to=thuth@redhat.com \
    --cc=afaerber@suse.de \
    --cc=agraf@csgraf.de \
    --cc=alex.bennee@linaro.org \
    --cc=berrange@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@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).