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 seldom
happens in the QEMU community, but for such rare cases it is preferrable
to have a basic code of conduct document available to show to people
who are misbehaving.  In case 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 tries to be short and to the point while
trying to remain friendly and welcoming; it is based on the Fedora Code
of Conduct[1] with extra detail added based on the Contributor Covenant
1.3.0[2].  Other proposals included the Contributor Covenant 1.3.0 itself
or the Django Code of Conduct[3] (which is also a derivative of Fedora's)
but, in any case, there was agreement on keeping the conflict resolution
policy separate from the CoC itself.

An important point is whether to apply the code of conduct to violations
that occur outside public spaces.  The text herein restricts that to
individuals acting as a representative or a member of the project or
its community.  This is intermediate between the Contributor Covenant
(which only mentions representatives of the community, for example using
an official project e-mail address or posting via an official social media
account), and the Django Code of Conduct, which says that violations of
this code outside these spaces "may" be considered but does not limit
this further.

The conflict resolution policy is based on the Drupal Conflict Resolution
Policy[4] and its derivative, the Mozilla Consequence Ladder[5].

[1] https://www.fedoraproject.com/code-of-conduct/
[2] https://www.contributor-covenant.org/version/1/3/0/code-of-conduct/
[3] https://www.djangoproject.com/conduct/
[4] https://www.drupal.org/conflict-resolution
[5] https://github.com/mozilla/diversity/blob/master/code-of-conduct-enforcement/consequence-ladder.md

Co-developed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
 docs/devel/code-of-conduct.rst     | 60 ++++++++++++++++++++++
 docs/devel/conflict-resolution.rst | 80 ++++++++++++++++++++++++++++++
 docs/devel/index.rst               |  2 +
 3 files changed, 142 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..83e8855250
--- /dev/null
+++ b/docs/devel/code-of-conduct.rst
@@ -0,0 +1,60 @@
+Code of Conduct
+===============
+
+The QEMU community is made up of a mixture of professionals and
+volunteers from all over the world. Diversity is one of our 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.
+
+* Be welcoming. We are committed to making participation in this project
+  a harassment-free experience for everyone, regardless of level of
+  experience, gender, gender identity and expression, sexual orientation,
+  disability, personal appearance, body size, race, ethnicity, age, religion,
+  or nationality.
+
+* Be respectful. Not all of us will agree all the time.  Disagreements, both
+  social and technical, happen all the time and the QEMU community is no
+  exception. When we disagree, we try to understand why.  It is important that
+  we resolve disagreements and differing views constructively.  Members of the
+  QEMU community should be respectful when dealing with other contributors as
+  well as with people outside the QEMU community and with users of QEMU.
+
+Harassment and other exclusionary behavior are not acceptable. A community
+where people feel uncomfortable or threatened is neither welcoming nor
+respectful.  Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery
+
+* Personal attacks
+
+* Trolling or insulting/derogatory comments
+
+* Public or private harassment
+
+* Publishing other's private information, such as physical or electronic
+addresses, without explicit permission
+
+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
+be excellent to each other.
+
+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. 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.
+
+By adopting this code of conduct, project maintainers commit themselves
+to fairly and consistently applying these principles to every aspect of
+managing this project.  If you believe someone is violating the code of
+conduct, please read the +:ref:`conflict-resolution` document for
+information about how to proceed.
+
+Sources
+-------
+
+This document is based on the `Fedora Code of Conduct
+<https://fedoraproject.org/code-of-conduct>`__ and the
+`Contributor Covenant version 1.3.0
+<https://www.contributor-covenant.org/version/1/3/0/code-of-conduct/>`__.
diff --git a/docs/devel/conflict-resolution.rst b/docs/devel/conflict-resolution.rst
new file mode 100644
index 0000000000..1e0bb41674
--- /dev/null
+++ b/docs/devel/conflict-resolution.rst
@@ -0,0 +1,80 @@
+.. _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, please consider first addressing the
+perceived conflict directly with other involved parties, preferably through
+a real-time medium such as IRC. You could also try to 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 this fails or if you do not feel comfortable proceeding this way, or
+if the problem requires immediate escalation, report the issue to the QEMU
+leadership committee by sending an email to qemu@sfconservancy.org, providing
+references to the misconduct.
+For very urgent topics, you can also 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>`__.
+
+Your report will be treated confidentially by the leadership committee and
+not be published without your agreement. The QEMU leadership committee will
+then do its best to review the incident timely, and will either seek further
+information, or will make a determination on next steps.
+
+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 temporary or permanent ban from some or all current and future QEMU
+   spaces (mailing lists, IRC, wiki, etc.), possibly including in-person
+   events.
+
+In the event of severe harassment, the leadership committee may advise that
+the matter be escalated to the relevant local law enforcement agency. It
+is however not the role of the leadership committee to initiate contact
+with law enforcement on behalf of any of the community members involved
+in an incident.
+
+Sources
+-------
+
+This document was developed based on the `Drupal Conflict Resolution
+Policy and Process <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>`__
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.30.1

On 31/03/2021 17.05, Paolo Bonzini 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 seldom
> happens in the QEMU community, but for such rare cases it is preferrable
> to have a basic code of conduct document available to show to people
> who are misbehaving.  In case 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 tries to be short and to the point while
> trying to remain friendly and welcoming; it is based on the Fedora Code
> of Conduct[1] with extra detail added based on the Contributor Covenant
> 1.3.0[2].  Other proposals included the Contributor Covenant 1.3.0 itself
> or the Django Code of Conduct[3] (which is also a derivative of Fedora's)
> but, in any case, there was agreement on keeping the conflict resolution
> policy separate from the CoC itself.
> 
> An important point is whether to apply the code of conduct to violations
> that occur outside public spaces.  The text herein restricts that to
> individuals acting as a representative or a member of the project or
> its community.  This is intermediate between the Contributor Covenant
> (which only mentions representatives of the community, for example using
> an official project e-mail address or posting via an official social media
> account), and the Django Code of Conduct, which says that violations of
> this code outside these spaces "may" be considered but does not limit
> this further.
> 
> The conflict resolution policy is based on the Drupal Conflict Resolution
> Policy[4] and its derivative, the Mozilla Consequence Ladder[5].
> 
> [1] https://www.fedoraproject.com/code-of-conduct/
> [2] https://www.contributor-covenant.org/version/1/3/0/code-of-conduct/
> [3] https://www.djangoproject.com/conduct/
> [4] https://www.drupal.org/conflict-resolution
> [5] https://github.com/mozilla/diversity/blob/master/code-of-conduct-enforcement/consequence-ladder.md
> 
> Co-developed-by: Thomas Huth <thuth@redhat.com>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
>   docs/devel/code-of-conduct.rst     | 60 ++++++++++++++++++++++
>   docs/devel/conflict-resolution.rst | 80 ++++++++++++++++++++++++++++++
>   docs/devel/index.rst               |  2 +
>   3 files changed, 142 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..83e8855250
> --- /dev/null
> +++ b/docs/devel/code-of-conduct.rst
> @@ -0,0 +1,60 @@
> +Code of Conduct
> +===============
> +
> +The QEMU community is made up of a mixture of professionals and
> +volunteers from all over the world. Diversity is one of our 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.
> +
> +* Be welcoming. We are committed to making participation in this project
> +  a harassment-free experience for everyone, regardless of level of
> +  experience, gender, gender identity and expression, sexual orientation,
> +  disability, personal appearance, body size, race, ethnicity, age, religion,
> +  or nationality.
> +
> +* Be respectful. Not all of us will agree all the time.  Disagreements, both
> +  social and technical, happen all the time and the QEMU community is no
> +  exception. When we disagree, we try to understand why.  It is important that
> +  we resolve disagreements and differing views constructively.  Members of the
> +  QEMU community should be respectful when dealing with other contributors as
> +  well as with people outside the QEMU community and with users of QEMU.
> +
> +Harassment and other exclusionary behavior are not acceptable. A community
> +where people feel uncomfortable or threatened is neither welcoming nor
> +respectful.  Examples of unacceptable behavior by participants include:
> +
> +* The use of sexualized language or imagery
> +
> +* Personal attacks
> +
> +* Trolling or insulting/derogatory comments
> +
> +* Public or private harassment
> +
> +* Publishing other's private information, such as physical or electronic
> +addresses, without explicit permission
> +
> +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

s/intended—a/intended — a/

With that fixed:

Reviewed-by: Thomas Huth <thuth@redhat.com>

Thanks for putting this together!


> +be excellent to each other.
> +
> +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. 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.
> +
> +By adopting this code of conduct, project maintainers commit themselves
> +to fairly and consistently applying these principles to every aspect of
> +managing this project.  If you believe someone is violating the code of
> +conduct, please read the +:ref:`conflict-resolution` document for
> +information about how to proceed.
> +
> +Sources
> +-------
> +
> +This document is based on the `Fedora Code of Conduct
> +<https://fedoraproject.org/code-of-conduct>`__ and the
> +`Contributor Covenant version 1.3.0
> +<https://www.contributor-covenant.org/version/1/3/0/code-of-conduct/>`__.
> diff --git a/docs/devel/conflict-resolution.rst b/docs/devel/conflict-resolution.rst
> new file mode 100644
> index 0000000000..1e0bb41674
> --- /dev/null
> +++ b/docs/devel/conflict-resolution.rst
> @@ -0,0 +1,80 @@
> +.. _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, please consider first addressing the
> +perceived conflict directly with other involved parties, preferably through
> +a real-time medium such as IRC. You could also try to 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 this fails or if you do not feel comfortable proceeding this way, or
> +if the problem requires immediate escalation, report the issue to the QEMU
> +leadership committee by sending an email to qemu@sfconservancy.org, providing
> +references to the misconduct.
> +For very urgent topics, you can also 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>`__.
> +
> +Your report will be treated confidentially by the leadership committee and
> +not be published without your agreement. The QEMU leadership committee will
> +then do its best to review the incident timely, and will either seek further
> +information, or will make a determination on next steps.
> +
> +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 temporary or permanent ban from some or all current and future QEMU
> +   spaces (mailing lists, IRC, wiki, etc.), possibly including in-person
> +   events.
> +
> +In the event of severe harassment, the leadership committee may advise that
> +the matter be escalated to the relevant local law enforcement agency. It
> +is however not the role of the leadership committee to initiate contact
> +with law enforcement on behalf of any of the community members involved
> +in an incident.
> +
> +Sources
> +-------
> +
> +This document was developed based on the `Drupal Conflict Resolution
> +Policy and Process <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>`__
> 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
> 

Il mer 31 mar 2021, 17:48 Thomas Huth <thuth@redhat.com> ha scritto:

> > +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
>
> s/intended—a/intended — a/
>

It looks ugly in monospace but it's the way em dashes are typically
formatted. The appropriate spacing is usually included in the font.

But a colon is even better than an em dash here. :) I'll keep your
Reviewed-by and wait anyway for others to chip in.

Paolo


> With that fixed:
>
> Reviewed-by: Thomas Huth <thuth@redhat.com>
>
> Thanks for putting this together!
>
>
> > +be excellent to each other.
> > +
> > +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. 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.
> > +
> > +By adopting this code of conduct, project maintainers commit themselves
> > +to fairly and consistently applying these principles to every aspect of
> > +managing this project.  If you believe someone is violating the code of
> > +conduct, please read the +:ref:`conflict-resolution` document for
> > +information about how to proceed.
> > +
> > +Sources
> > +-------
> > +
> > +This document is based on the `Fedora Code of Conduct
> > +<https://fedoraproject.org/code-of-conduct>`__ and the
> > +`Contributor Covenant version 1.3.0
> > +<https://www.contributor-covenant.org/version/1/3/0/code-of-conduct/
> >`__.
> > diff --git a/docs/devel/conflict-resolution.rst
> b/docs/devel/conflict-resolution.rst
> > new file mode 100644
> > index 0000000000..1e0bb41674
> > --- /dev/null
> > +++ b/docs/devel/conflict-resolution.rst
> > @@ -0,0 +1,80 @@
> > +.. _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, please consider first addressing the
> > +perceived conflict directly with other involved parties, preferably
> through
> > +a real-time medium such as IRC. You could also try to 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 this fails or if you do not feel comfortable proceeding this way, or
> > +if the problem requires immediate escalation, report the issue to the
> QEMU
> > +leadership committee by sending an email to qemu@sfconservancy.org,
> providing
> > +references to the misconduct.
> > +For very urgent topics, you can also 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>`__.
> > +
> > +Your report will be treated confidentially by the leadership committee
> and
> > +not be published without your agreement. The QEMU leadership committee
> will
> > +then do its best to review the incident timely, and will either seek
> further
> > +information, or will make a determination on next steps.
> > +
> > +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 temporary or permanent ban from some or all current and future QEMU
> > +   spaces (mailing lists, IRC, wiki, etc.), possibly including in-person
> > +   events.
> > +
> > +In the event of severe harassment, the leadership committee may advise
> that
> > +the matter be escalated to the relevant local law enforcement agency. It
> > +is however not the role of the leadership committee to initiate contact
> > +with law enforcement on behalf of any of the community members involved
> > +in an incident.
> > +
> > +Sources
> > +-------
> > +
> > +This document was developed based on the `Drupal Conflict Resolution
> > +Policy and Process <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
> >`__
> > 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
> >
>
>

On Wednesday, 2021-03-31 at 17:05:27 +02, Paolo Bonzini 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 seldom
> happens in the QEMU community, but for such rare cases it is preferrable
> to have a basic code of conduct document available to show to people
> who are misbehaving.  In case 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 tries to be short and to the point while
> trying to remain friendly and welcoming; it is based on the Fedora Code
> of Conduct[1] with extra detail added based on the Contributor Covenant
> 1.3.0[2].  Other proposals included the Contributor Covenant 1.3.0 itself
> or the Django Code of Conduct[3] (which is also a derivative of Fedora's)
> but, in any case, there was agreement on keeping the conflict resolution
> policy separate from the CoC itself.
>
> An important point is whether to apply the code of conduct to violations
> that occur outside public spaces.  The text herein restricts that to
> individuals acting as a representative or a member of the project or
> its community.  This is intermediate between the Contributor Covenant
> (which only mentions representatives of the community, for example using
> an official project e-mail address or posting via an official social media
> account), and the Django Code of Conduct, which says that violations of
> this code outside these spaces "may" be considered but does not limit
> this further.
>
> The conflict resolution policy is based on the Drupal Conflict Resolution
> Policy[4] and its derivative, the Mozilla Consequence Ladder[5].
>
> [1] https://www.fedoraproject.com/code-of-conduct/
> [2] https://www.contributor-covenant.org/version/1/3/0/code-of-conduct/
> [3] https://www.djangoproject.com/conduct/
> [4] https://www.drupal.org/conflict-resolution
> [5] https://github.com/mozilla/diversity/blob/master/code-of-conduct-enforcement/consequence-ladder.md
>
> Co-developed-by: Thomas Huth <thuth@redhat.com>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
>  docs/devel/code-of-conduct.rst     | 60 ++++++++++++++++++++++
>  docs/devel/conflict-resolution.rst | 80 ++++++++++++++++++++++++++++++
>  docs/devel/index.rst               |  2 +
>  3 files changed, 142 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..83e8855250
> --- /dev/null
> +++ b/docs/devel/code-of-conduct.rst
> @@ -0,0 +1,60 @@
> +Code of Conduct
> +===============
> +
> +The QEMU community is made up of a mixture of professionals and
> +volunteers from all over the world. Diversity is one of our 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.
> +
> +* Be welcoming. We are committed to making participation in this project
> +  a harassment-free experience for everyone, regardless of level of
> +  experience, gender, gender identity and expression, sexual orientation,
> +  disability, personal appearance, body size, race, ethnicity, age, religion,
> +  or nationality.
> +
> +* Be respectful. Not all of us will agree all the time.  Disagreements, both
> +  social and technical, happen all the time and the QEMU community is no
> +  exception. When we disagree, we try to understand why.  It is important that
> +  we resolve disagreements and differing views constructively.  Members of the
> +  QEMU community should be respectful when dealing with other contributors as
> +  well as with people outside the QEMU community and with users of QEMU.
> +
> +Harassment and other exclusionary behavior are not acceptable. A community
> +where people feel uncomfortable or threatened is neither welcoming nor
> +respectful.  Examples of unacceptable behavior by participants include:
> +
> +* The use of sexualized language or imagery
> +
> +* Personal attacks
> +
> +* Trolling or insulting/derogatory comments
> +
> +* Public or private harassment
> +
> +* Publishing other's private information, such as physical or electronic
> +addresses, without explicit permission
> +
> +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
> +be excellent to each other.
> +
> +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. 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.
> +
> +By adopting this code of conduct, project maintainers commit themselves
> +to fairly and consistently applying these principles to every aspect of
> +managing this project.  If you believe someone is violating the code of
> +conduct, please read the +:ref:`conflict-resolution` document for
> +information about how to proceed.
> +
> +Sources
> +-------
> +
> +This document is based on the `Fedora Code of Conduct
> +<https://fedoraproject.org/code-of-conduct>`__ and the
> +`Contributor Covenant version 1.3.0
> +<https://www.contributor-covenant.org/version/1/3/0/code-of-conduct/>`__.
> diff --git a/docs/devel/conflict-resolution.rst b/docs/devel/conflict-resolution.rst
> new file mode 100644
> index 0000000000..1e0bb41674
> --- /dev/null
> +++ b/docs/devel/conflict-resolution.rst
> @@ -0,0 +1,80 @@
> +.. _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, please consider first addressing the
> +perceived conflict directly with other involved parties, preferably through
> +a real-time medium such as IRC. You could also try to 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 this fails or if you do not feel comfortable proceeding this way, or
> +if the problem requires immediate escalation, report the issue to the QEMU
> +leadership committee by sending an email to qemu@sfconservancy.org, providing
> +references to the misconduct.
> +For very urgent topics, you can also 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>`__.
> +
> +Your report will be treated confidentially by the leadership committee and
> +not be published without your agreement. The QEMU leadership committee will
> +then do its best to review the incident timely, and will either seek further

s/timely/in a timely manner/ ?

> +information, or will make a determination on next steps.
> +
> +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 temporary or permanent ban from some or all current and future QEMU
> +   spaces (mailing lists, IRC, wiki, etc.), possibly including in-person
> +   events.
> +
> +In the event of severe harassment, the leadership committee may advise that
> +the matter be escalated to the relevant local law enforcement agency. It
> +is however not the role of the leadership committee to initiate contact
> +with law enforcement on behalf of any of the community members involved
> +in an incident.
> +
> +Sources
> +-------
> +
> +This document was developed based on the `Drupal Conflict Resolution
> +Policy and Process <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>`__
> 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.30.1

dme.
-- 
I got a girlfriend that's better than that.

Paolo Bonzini <pbonzini@redhat.com> writes:

<snip>
> +
> +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
> +be excellent to each other.

I think a colon might work better here:

  Rather, take it in the spirit in which it's intended: a guide to make it
  easier to be excellent to each other.

Other that that all looks good to me.

Reviewed-by: Alex Bennée <alex.bennee@linaro.org>

-- 
Alex Bennée

Am 31.03.2021 um 17:05 hat Paolo Bonzini geschrieben:
> +respectful.  Examples of unacceptable behavior by participants include:
> +
> +* The use of sexualized language or imagery
> +
> +* Personal attacks
> +
> +* Trolling or insulting/derogatory comments
> +
> +* Public or private harassment
> +
> +* Publishing other's private information, such as physical or electronic
> +addresses, without explicit permission

"Electronic addresses"? No more Cc: in emails without asking for
explicit permission first in each case, especially when looping in
people who are not subscribed to the list? And the same for attribution
in commits (turning informal statements into Reported-by, Acked-by
etc.)? Links to git repositories of other people?

I'm sure that this is not what was intended, but it's pretty clearly the
implication of what is written here.

(This kind of "bugs" is one of the reasons why I'm not a huge fan of
written rules instead of trusting the judgement of community leaders.
In the communities I am involved in, I can't remember many cases where
they actually helped to resolve conflicts, but I can remember many
unproductive discussions about how to interpret the written text and
what it does and doesn't cover.)

Kevin

Kevin Wolf <kwolf@redhat.com> writes:

> Am 31.03.2021 um 17:05 hat Paolo Bonzini geschrieben:
>> +respectful.  Examples of unacceptable behavior by participants include:
>> +
>> +* The use of sexualized language or imagery
>> +
>> +* Personal attacks
>> +
>> +* Trolling or insulting/derogatory comments
>> +
>> +* Public or private harassment
>> +
>> +* Publishing other's private information, such as physical or electronic
>> +addresses, without explicit permission
>
> "Electronic addresses"? No more Cc: in emails without asking for
> explicit permission first in each case, especially when looping in
> people who are not subscribed to the list? And the same for attribution
> in commits (turning informal statements into Reported-by, Acked-by
> etc.)? Links to git repositories of other people?
>
> I'm sure that this is not what was intended, but it's pretty clearly the
> implication of what is written here.

I'm pretty sure emails used to post to public mailing lists (or used in
a dco tag) are considered public pieces of information. I read the above
as covering things that are not public such as private email addresses
or chat ids and the likes.

> (This kind of "bugs" is one of the reasons why I'm not a huge fan of
> written rules instead of trusting the judgement of community leaders.
> In the communities I am involved in, I can't remember many cases where
> they actually helped to resolve conflicts, but I can remember many
> unproductive discussions about how to interpret the written text and
> what it does and doesn't cover.)

Well we don't have to start here ;-)

We explicitly try to avoid rules lawyering with the very next statement:

  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
  be excellent to each other.

-- 
Alex Bennée

Am 07.04.2021 um 15:35 hat Alex Bennée geschrieben:
> Kevin Wolf <kwolf@redhat.com> writes:
> > Am 31.03.2021 um 17:05 hat Paolo Bonzini geschrieben:
> >> +respectful.  Examples of unacceptable behavior by participants include:
> >> +
> >> +* The use of sexualized language or imagery
> >> +
> >> +* Personal attacks
> >> +
> >> +* Trolling or insulting/derogatory comments
> >> +
> >> +* Public or private harassment
> >> +
> >> +* Publishing other's private information, such as physical or electronic
> >> +addresses, without explicit permission
> >
> > "Electronic addresses"? No more Cc: in emails without asking for
> > explicit permission first in each case, especially when looping in
> > people who are not subscribed to the list? And the same for attribution
> > in commits (turning informal statements into Reported-by, Acked-by
> > etc.)? Links to git repositories of other people?
> >
> > I'm sure that this is not what was intended, but it's pretty clearly the
> > implication of what is written here.
> 
> I'm pretty sure emails used to post to public mailing lists (or used
> in a dco tag) are considered public pieces of information. I read the
> above as covering things that are not public such as private email
> addresses or chat ids and the likes.

Yes, it's pretty clear that I'm not publishing new information about
people when I'm keeping them in Cc: when replying to a thread, or even
when they posted in another thread on the list recently. It becomes much
less clear for adding people who aren't usually part of the QEMU
community.

> > (This kind of "bugs" is one of the reasons why I'm not a huge fan of
> > written rules instead of trusting the judgement of community leaders.
> > In the communities I am involved in, I can't remember many cases where
> > they actually helped to resolve conflicts, but I can remember many
> > unproductive discussions about how to interpret the written text and
> > what it does and doesn't cover.)
> 
> Well we don't have to start here ;-)
> 
> We explicitly try to avoid rules lawyering with the very next statement:
> 
>   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
>   be excellent to each other.

Right, though it doesn't make any of the above rules any less strict. It
just tells me that I'm still in danger even if I follow the explicitly
mentioned things.

This might be the worst of both worlds: We explicitly threaten people
with consequences if they don't keep the rules, but then we don't tell
them what the rules even are and say they should use common sense
("you'll find out what the rules were when we punish you for breaking
them").

I _think_ I'm usually not misbehaving, but how can I know for sure that
others have the same impression? For me, this creates a situation of
uncertainty, and uncertainty makes me feel uneasy. Maybe I'm the only
one, though, and the benefits outweigh my uneasiness.

Kevin

On 07/04/21 17:42, Kevin Wolf wrote:
>> +* Publishing other's private information, such as physical or electronic
>> +addresses, without explicit permission
>
> Yes, it's pretty clear that I'm not publishing new information about
> people when I'm keeping them in Cc: when replying to a thread, or even
> when they posted in another thread on the list recently. It becomes much
> less clear for adding people who aren't usually part of the QEMU
> community.

If you took the email from, say, the Libvirt or kernel mailing lists, 
that would not be considered private.  If somebody has two email 
addresses and you deliberately Cc him on an address that he's only using 
for communications within his family, that would be a problem.

I agree that this doxing is unlikely to happen since our communication 
revolves on email and we generally don't accept pseudonymous 
contributions.  But even there, we have had historically a couple 
exceptions to the no-pseudonyms rule.

Paolo

Hi Paolo,

On 13.04.21 09:42, Paolo Bonzini wrote:
> On 07/04/21 17:42, Kevin Wolf wrote:
>>> +* Publishing other's private information, such as physical or
>>> electronic
>>> +addresses, without explicit permission
>>
>> Yes, it's pretty clear that I'm not publishing new information about
>> people when I'm keeping them in Cc: when replying to a thread, or even
>> when they posted in another thread on the list recently. It becomes much
>> less clear for adding people who aren't usually part of the QEMU
>> community.
> 
> If you took the email from, say, the Libvirt or kernel mailing lists,
> that would not be considered private.  If somebody has two email
> addresses and you deliberately Cc him on an address that he's only using
> for communications within his family, that would be a problem.

I have to admit I had originally stumbled over this bullet point myself,
reading it as private=personal. So maybe it might help avoid ambiguities
for non-native readers to formulate it as "non-public" instead?

Like, if someone posts to a public mailing list with their private as
opposed to business address in the footer. Then I would consider it
public. I did intentionally use a private email for topics such as PReP.

Or consider the case you get a bug report not copied to the public
mailing lists from someone you don't know. Then I would still expect to
be allowed to attribute a commit via Reported-by/CC to that person, as
it seems in his/her interest to get the bug fixed and be notified,
unless explicitly requested otherwise.

Mistakes can always happen, but I feel it needs to be the responsibility
of the sender, not of the receiver, to ensure that only data is shared
that the project members may use for valid development purposes.

Not sure how to extend that bullet point to make its purpose/scope clearer.

Cheers,
Andreas

-- 
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 36809 (AG Nürnberg)

On Tue, 13 Apr 2021 at 11:23, Andreas Färber <afaerber@suse.de> wrote:
> Or consider the case you get a bug report not copied to the public
> mailing lists from someone you don't know. Then I would still expect to
> be allowed to attribute a commit via Reported-by/CC to that person, as
> it seems in his/her interest to get the bug fixed and be notified,
> unless explicitly requested otherwise.

FWIW, in this kind of situation, I generally try to explicitly
ask the submitter if they're OK with my adding a reported-by
tag, just as a matter of politeness. Not everybody is OK with
having their email address publicly recorded on mailing list
archives and in git history forever.

thanks
-- PMM

Peter Maydell <peter.maydell@linaro.org> writes:

> On Tue, 13 Apr 2021 at 11:23, Andreas Färber <afaerber@suse.de> wrote:
>> Or consider the case you get a bug report not copied to the public
>> mailing lists from someone you don't know. Then I would still expect to
>> be allowed to attribute a commit via Reported-by/CC to that person, as
>> it seems in his/her interest to get the bug fixed and be notified,
>> unless explicitly requested otherwise.
>
> FWIW, in this kind of situation, I generally try to explicitly
> ask the submitter if they're OK with my adding a reported-by
> tag, just as a matter of politeness. Not everybody is OK with
> having their email address publicly recorded on mailing list
> archives and in git history forever.

That's what I'd do, too.

Still, neglecting to ask for permission to publicly credit a bug report
is not anywhere near doxing.  If the public credit turns out to be
unwanted, a sincere apology is obviously called for.  People may exist
who need to be slapped over the head with a code of conduct to figure
that out.  I hope we'll never need to do that.

Anyway.  What I see at work here is one of the unintended consequences
of formal codes of conduct: they read like law, so people read them
lawyerly.  Our CoC attempts to avoid this by explicitly stating its
*purpose*: "a guide to make it easier to be excellent to each other."

This applies to the QEMU leadership committee in spades.  Treating
negligent publication of some technical e-mail's sender address as
malicious doxing wouldn't be excellent to anyone, it would be the
leadership committee shooting themselves into the foot with a machine
gun".

Let's not worry about that, okay?