In an ideal world, we would all get along together very well, always be
polite and never end up in huge conflicts. And even if there are conflicts,
we would always handle each other fair and respectfully. Unfortunately,
this is not an ideal world and sometimes people forget how to interact with
each other in a professional and respectful way. Fortunately, this rarely
happens in the QEMU community, but still there are such rare cases, and
then it would be good to have a basic code of conduct document available
that can be shown to persons who are misbehaving. And if that does not help
yet, we should also have a conflict resolution policy ready that can be
applied in the worst case.

The Code of Conduct document is based on the Django Code of Conduct
(https://www.djangoproject.com/conduct/) and the conflict resolution
has been assembled by Paolo, based on the Drupal Conflict Resolution Policy
(https://www.drupal.org/conflict-resolution) and the Mozilla Consequence Ladder
(https://github.com/mozilla/diversity/blob/master/code-of-conduct-enforcement/consequence-ladder.md)

Signed-off-by: Thomas Huth <thuth@redhat.com>
---
 Discussion about a Code of Conduct already started off-list last summer,
 but it unfortunately ceased without a result. Let's have another try
 now by discussing this suggestion publically. I've picked the Django Code
 of Conduct as a base, since it sounds rather friendly and still welcoming
 to me, but I'm open for other suggestions, too.

 docs/devel/code-of-conduct.rst     | 85 ++++++++++++++++++++++++++++++
 docs/devel/conflict-resolution.rst | 85 ++++++++++++++++++++++++++++++
 docs/devel/index.rst               |  2 +
 3 files changed, 172 insertions(+)
 create mode 100644 docs/devel/code-of-conduct.rst
 create mode 100644 docs/devel/conflict-resolution.rst

diff --git a/docs/devel/code-of-conduct.rst b/docs/devel/code-of-conduct.rst
new file mode 100644
index 0000000000..050dbd9e16
--- /dev/null
+++ b/docs/devel/code-of-conduct.rst
@@ -0,0 +1,85 @@
+Code of Conduct
+===============
+
+Like the technical community as a whole, the QEMU community is made up of a
+mixture of professionals and volunteers from all over the world.
+Diversity is one of our huge strengths, but it can also lead to communication
+issues and unhappiness. To that end, we have a few ground rules that we ask
+people to adhere to. This code applies equally to founders, maintainers,
+contributors, mentors and those seeking help and guidance.
+
+This isn't an exhaustive list of things that you can't do. Rather, take it in
+the spirit in which it's intended - a guide to make it easier to enrich all of
+us and the technical communities in which we participate:
+
+* Be friendly and patient.
+
+* Be welcoming. We strive to be a community that welcomes and supports people
+  of all backgrounds and identities. This includes, but is not limited to
+  members of any race, ethnicity, culture, national origin, colour, immigration
+  status, social and economic class, educational level, sex, sexual orientation,
+  gender identity and expression, age, size, family status, political belief,
+  religion, and mental and physical ability.
+
+* Be considerate. Your work will be used by other people, and you in turn will
+  depend on the work of others. Any decision you take will affect users and
+  colleagues, and you should take those consequences into account when making
+  decisions. Remember that we're a world-wide community, so you might not be
+  communicating in someone else's primary language.
+
+* Be respectful. Not all of us will agree all the time, but disagreement is no
+  excuse for poor behavior and poor manners. We might all experience some
+  frustration now and then, but we cannot allow that frustration to turn into
+  a personal attack. It's important to remember that a community where people
+  feel uncomfortable or threatened is not a productive one. Members of the QEMU
+  community should be respectful when dealing with other members as well as
+  with people outside the QEMU community.
+
+* Be careful in the words that you choose. We are a community of professionals,
+  and we conduct ourselves professionally. Be kind to others. Do not insult or
+  put down other participants. Harassment and other exclusionary behavior
+  aren't acceptable. This includes, but is not limited to:
+
+  * Violent threats or language directed against another person.
+
+  * Discriminatory jokes and language.
+
+  * Posting sexually explicit or violent material.
+
+  * Posting (or threatening to post) other people's personally identifying
+    information ("doxing").
+
+  * Personal insults, especially those using racist or sexist terms.
+
+  * Unwelcome sexual attention.
+
+  * Advocating for, or encouraging, any of the above behavior.
+
+  * Repeated harassment of others. In general, if someone asks you to stop,
+    then stop.
+
+* When we disagree, try to understand why. Disagreements, both social and
+  technical, happen all the time and our project is no exception. It is
+  important that we resolve disagreements and differing views constructively.
+  Remember that we're different. The strength of our project comes from its
+  varied community, people from a wide range of backgrounds. Different people
+  have different perspectives on issues. Being unable to understand why someone
+  holds a viewpoint doesn't mean that they're wrong. Don't forget that it is
+  human to err and blaming each other doesn't get us anywhere. Instead, focus
+  on helping to resolve issues and learning from mistakes.
+
+This code of conduct applies to all spaces managed by the QEMU project. This
+includes IRC, the mailing lists, the issue tracker, community events, and any
+other forums created by the project team which the community uses for
+communication. In addition, violations of this code outside these spaces may
+affect a person's ability to participate within them.
+
+If you believe someone is violating the code of conduct, please read the
+:ref:`conflict-resolution` document for information about how to proceed.
+
+This document is based on the `Django Code of Conduct
+<https://www.djangoproject.com/conduct/>`__, with original text courtesy of the
+`Speak Up! project
+<http://web.archive.org/web/20141109123859/http://speakup.io/coc.html>`__
+(`CC BY 3.0 <https://creativecommons.org/licenses/by/3.0/>`__).
+
diff --git a/docs/devel/conflict-resolution.rst b/docs/devel/conflict-resolution.rst
new file mode 100644
index 0000000000..4eb4fb45df
--- /dev/null
+++ b/docs/devel/conflict-resolution.rst
@@ -0,0 +1,85 @@
+.. _conflict-resolution:
+
+Conflict Resolution Policy
+==========================
+
+Conflicts in the community can take many forms, from someone having a
+bad day and using harsh and hurtful language on the mailing list to more
+serious code of conduct violations (including sexist/racist statements
+or threats of violence), and everything in between.
+
+For the vast majority of issues, we aim to empower individuals to first
+resolve conflicts themselves, asking for help when needed, and only
+after that fails to escalate further. This approach gives people more
+control over the outcome of their dispute.
+
+How we resolve conflicts
+------------------------
+
+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, get a third-party (e.g. a
+mutual friend, and/or someone with background on the issue, but not
+involved in the conflict) to intercede or mediate.
+
+If you are witnessing conflict, you should also first try to address it
+directly by interceding or mediating between the involved parties.
+
+If a good faith effort towards resolving the conflict fails,
+escalate to the QEMU leadership committee by sending email at
+qemu@sfconservancy.org. It is strongly suggested to include evidence of
+past effort towards resolving the conflict.
+
+The QEMU leadership committee will do its best to review the incident
+timely, and will either seek further information, or will make a
+determination on next steps.
+
+Note: If the behaviour is threatening/harassing and requires immediate
+escalation, contact the QEMU leadership committee immediately before
+trying other steps, and possibly inform one or more members through IRC.
+The up-to-date list of members is `available on the QEMU wiki
+<https://wiki.qemu.org/Conservancy>`__.
+
+Remedies
+--------
+
+Escalating an issue to the QEMU leadership committee may result in actions
+impacting one or more involved parties. In the event the leadership
+committee has to intervene, here are some of the ways they might respond:
+
+1. Take no action. For example, if the leadership committee determines
+the complaint has not been substantiated or is being made in bad faith,
+or if it is deemed to be outside its purview.
+
+2. A private reprimand, explaining the consequences of continued behavior,
+to one or more involved individuals.
+
+3. A private reprimand and request for a private or public apology
+
+4. A public reprimand and request for a public apology
+
+5. A public reprimand plus a mandatory cooling off period. The cooling
+off period may require, for example, one or more of the following:
+abstaining from maintainer duties; not interacting with people involved,
+including unsolicited interaction with those enforcing the guidelines
+and interaction on social media; being denied participation to in-person
+events.  The cooling off period is voluntary but may escalate to a
+temporary ban in order to enforce it.
+
+6. A permanent or temporary ban from some or all QEMU spaces (mailing
+lists, IRC, wiki, etc.). The group will maintain records of all such
+bans so that they may be reviewed in the future, extended to new fora,
+or otherwise maintained.
+
+In the event of severe harassment, the leadership comittee may advise that
+the matter be escalated to the relevant local law enforcement agency. It
+is however not the role of the leadership comittee to initiate contact
+with law enforcement on behalf of any of the community members involved
+in an incident.
+
+Sources
+-------
+
+* `Drupal Conflict Resolution Policy and Process <https://www.drupal.org/conflict-resolution>`__
+
+* `Mozilla Consequence Ladder <https://github.com/mozilla/diversity/blob/master/code-of-conduct-enforcement/consequence-ladder.md>`__
diff --git a/docs/devel/index.rst b/docs/devel/index.rst
index 7c424ea6d7..416261505f 100644
--- a/docs/devel/index.rst
+++ b/docs/devel/index.rst
@@ -14,6 +14,8 @@ Contents:
    :maxdepth: 2
    :includehidden:
 
+   code-of-conduct
+   conflict-resolution
    build-system
    style
    kconfig
-- 
2.27.0

On Mon, Mar 29, 2021 at 08:01:40PM +0200, Thomas Huth wrote:
> In an ideal world, we would all get along together very well, always be
> polite and never end up in huge conflicts. And even if there are conflicts,
> we would always handle each other fair and respectfully. Unfortunately,
> this is not an ideal world and sometimes people forget how to interact with
> each other in a professional and respectful way. Fortunately, this rarely
> happens in the QEMU community, but still there are such rare cases, and
> then it would be good to have a basic code of conduct document available
> that can be shown to persons who are misbehaving. And if that does not help
> yet, we should also have a conflict resolution policy ready that can be
> applied in the worst case.
> 
> The Code of Conduct document is based on the Django Code of Conduct
> (https://www.djangoproject.com/conduct/) and the conflict resolution
> has been assembled by Paolo, based on the Drupal Conflict Resolution Policy
> (https://www.drupal.org/conflict-resolution) and the Mozilla Consequence Ladder
> (https://github.com/mozilla/diversity/blob/master/code-of-conduct-enforcement/consequence-ladder.md)
> 
> Signed-off-by: Thomas Huth <thuth@redhat.com>
> ---
>  Discussion about a Code of Conduct already started off-list last summer,
>  but it unfortunately ceased without a result. Let's have another try
>  now by discussing this suggestion publically. I've picked the Django Code
>  of Conduct as a base, since it sounds rather friendly and still welcoming
>  to me, but I'm open for other suggestions, too.

The obvious alternative is to import the contributor covenant

  https://www.contributor-covenant.org/

IMHO the biggest appealing reason is that it is a defacto
common standard across a huge number of open source projects.

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.

I tend to view this similarly to license choice. It is almost
always better to adopt a commonly accepted standard as-i,s than
to have something custom to just one project, even if it was
derived from / inspired by another well known example project's
own example.

Overall I think it is a good idea to introduce an explicit CoC
doc to QEMU, and indeed any community project, so thanks for
bringing this up again.

> 
>  docs/devel/code-of-conduct.rst     | 85 ++++++++++++++++++++++++++++++
>  docs/devel/conflict-resolution.rst | 85 ++++++++++++++++++++++++++++++
>  docs/devel/index.rst               |  2 +
>  3 files changed, 172 insertions(+)
>  create mode 100644 docs/devel/code-of-conduct.rst
>  create mode 100644 docs/devel/conflict-resolution.rst
> 


> diff --git a/docs/devel/conflict-resolution.rst b/docs/devel/conflict-resolution.rst
> new file mode 100644
> index 0000000000..4eb4fb45df
> --- /dev/null
> +++ b/docs/devel/conflict-resolution.rst
> @@ -0,0 +1,85 @@
> +.. _conflict-resolution:
> +
> +Conflict Resolution Policy
> +==========================
> +
> +Conflicts in the community can take many forms, from someone having a
> +bad day and using harsh and hurtful language on the mailing list to more
> +serious code of conduct violations (including sexist/racist statements
> +or threats of violence), and everything in between.
> +
> +For the vast majority of issues, we aim to empower individuals to first
> +resolve conflicts themselves, asking for help when needed, and only
> +after that fails to escalate further. This approach gives people more
> +control over the outcome of their dispute.
> +
> +How we resolve conflicts
> +------------------------
> +
> +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, get a third-party (e.g. a
> +mutual friend, and/or someone with background on the issue, but not
> +involved in the conflict) to intercede or mediate.
> +
> +If you are witnessing conflict, you should also first try to address it
> +directly by interceding or mediating between the involved parties.
> +
> +If a good faith effort towards resolving the conflict fails,
> +escalate to the QEMU leadership committee by sending email at
> +qemu@sfconservancy.org. It is strongly suggested to include evidence of
> +past effort towards resolving the conflict.
> +
> +The QEMU leadership committee will do its best to review the incident
> +timely, and will either seek further information, or will make a
> +determination on next steps.
> +
> +Note: If the behaviour is threatening/harassing and requires immediate
> +escalation, contact the QEMU leadership committee immediately before
> +trying other steps, and possibly inform one or more members through IRC.
> +The up-to-date list of members is `available on the QEMU wiki
> +<https://wiki.qemu.org/Conservancy>`__.

I feel this section is rather disjoint. First repeatedly saying the
victim must try to resolve it themselves, and must provide prove of
trying to resolve it when escalating. Then at the end saying you can
ignore this and escalate immediately but only in certain nominated
circumstances. I get what this is trying to achieve, but I feel it
is overly complicated and first part comes across as putting the
burden on the person suffering to take the lead in resolving problems.

I feel the contributor covenant is clearer in this area through its
simplicity

Also this document doesn't mention anything about ensuring the
confidentiality/privacy for any complaints reported, which I
think is important to state explicitly.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Il lun 29 mar 2021, 20:33 Daniel P. Berrangé <berrange@redhat.com> ha
scritto:

> The obvious alternative is to import the contributor covenant
>
>   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.

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.

Overall I think it is a good idea to introduce an explicit CoC
> doc to QEMU, and indeed any community project, so thanks for
> bringing this up again.
>

Agreed!

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

Thanks,

Paolo


>
> Regards,
> Daniel
> --
> |: https://berrange.com      -o-
> https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org         -o-
> https://fstop138.berrange.com :|
> |: https://entangle-photo.org    -o-
> https://www.instagram.com/dberrange :|
>
>

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

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

On Mon, Mar 29, 2021 at 10:59:23PM +0200, Paolo Bonzini wrote:
> Il lun 29 mar 2021, 20:33 Daniel P. Berrangé <berrange@redhat.com> ha
> scritto:
> 
> > The obvious alternative is to import the contributor covenant
> >
> >   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.
> 
> 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.

Note, I didn't say we should automatically upgrade - I said we can
choose to upgrade. 


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|