From: Paolo Bonzini <pbonzini@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
"Thomas Huth" <thuth@redhat.com>,
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 v2] docs: Add a QEMU Code of Conduct and Conflict Resolution Policy document
Date: Tue, 30 Mar 2021 16:07:06 +0200 [thread overview]
Message-ID: <c9ae35d4-65c3-980a-aaf3-e4be58b68d24@redhat.com> (raw)
In-Reply-To: <YGMhUTUXJBM3BcW5@redhat.com>
On 30/03/21 15:02, Daniel P. Berrangé wrote:
> Consider someone is kicked out from another project for violation
> of that project's CoC, that would also be considered a violation
> under QEMU's CoC. This qualifier is explicitly stating that the CoC
> violation in the other project has no bearing on whether that
> person can now start participating in QEMU. I think that's a bad
> mixed message we're sending there. It is especially poor if the
> victim from the other project is also a QEMU contributor.
My wording is actually already broader than what is in the contributor
covenant:
This Code of Conduct applies within all project spaces, and it also
applies when an individual is representing the project or its
community in public spaces. Examples of representing a project or
community include using an official project e-mail address, posting
via an official social media account, or acting as an appointed
representative at an online or offline event.
That is, the Code of Conduct would not apply to someone saying "the QEMU
SCSI maintainer rejected my patches, he is an idiot" on Twitter. My
proposal sought to find a middle ground, where that person could be
reasonably considered to be "acting as a member of the project or its
community".
> The wording Thomas' draft has
>
> In addition, violations of this code outside these spaces may
> affect a person's ability to participate within them.
>
> doesn't require QEMU to take action. It just set a statement
> of intent that gives QEMU the freedom to evaluate whether it is
> reasonable to take action to protect its contributors, should a
> contributor wish to raise an issue that occurred outside QEMU.
There have been in the past cases of external people asking projects to
ban contributors because of views they held on social media. The
Contributor Covenant initially included no limit to the application of
the CoC and only added a limitation after the author herself was
involved in such an episode[1][2].
I would prefer to avoid putting QEMU in that situation, and limit the
applicability code of conduct as much as possible to conflicts within
the community.
The Mozilla participation guidelines (2165 words :)) acknowledge that
"it is possible for actions taken outside of Mozilla's online or in
person spaces to have a deep impact on community health" but also admit
that "this is an active topic in the diversity and inclusion realm"[3].
The Django code of conduct seems to be in the minority in having such a
broad applicability, while the wording in the Contributor Covenant seems
to be more informed by actual experience.
Paolo
[1] https://github.com/opal/opal/issues/941 (June 18, 2015)
[2]
https://github.com/ContributorCovenant/contributor_covenant/commit/c400f17438
(June 19, 2015)
[3] https://www.mozilla.org/en-US/about/governance/policies/participation/
next prev parent reply other threads:[~2021-03-30 14:08 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-30 9:08 [PATCH v2] docs: Add a QEMU Code of Conduct and Conflict Resolution Policy document Thomas Huth
2021-03-30 10:53 ` Paolo Bonzini
2021-03-30 13:02 ` Daniel P. Berrangé
2021-03-30 14:07 ` Paolo Bonzini [this message]
2021-03-31 8:33 ` Daniel P. Berrangé
2021-03-31 5:40 ` Thomas Huth
2021-03-31 6:50 ` 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=c9ae35d4-65c3-980a-aaf3-e4be58b68d24@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).