Message ID | 20210331150527.14857-1-pbonzini@redhat.com |
---|---|
State | New |
Headers | show |
Series | docs: Add a QEMU Code of Conduct and Conflict Resolution Policy document | expand |
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.
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>
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.
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 Wed, Apr 07, 2021 at 05:42:01PM +0200, Kevin Wolf wrote: > 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. I think you need to bear in mind that we're not using some crude AI to apply blind enforcement of rules. The people responsible for any enforcement have the ability to apply common sense to situation and so aren't likely to take action if someone complains about "publishing" an email address by adding it to a CC on a thread / git commit message. Similarly if you think you are not misbehaving, then almost always that will indeed be the case. If someone did happen to disagree though, then the CoC sets out a process for resolving the situation and that process doesn't have to result in action being taken. It could easily simply be a case of explaining a mis-understanding between two people, and hopefully that would even be the common case. If we don't have any CoC then that creates much worse uncertainty because people who are on the receiving end of bad behaviour will have no idea whether the QEMU project as a whole even cares about it, or whether it is the kind of thing that will lead to action being taken, or whom to talk to about it. A CoC isn't going to magically stop all bad behaviour, but it does give the victims clarity of what the expected standards of decency are, and how to handle the situations. It also gives QEMU community members in general confidence in speaking up if they see bad behaviour, instead of having to wait for some senior project member to see the issue and take action. We've been lucky in the past that when bad situations have arisen on qemu-devel, the right senior people happened to be online and dealt with it, but I would rather we had had a CoC then, that made it clearer. Regards, Daniel
On 07/04/2021 18.03, Daniel P. Berrangé wrote: > On Wed, Apr 07, 2021 at 05:42:01PM +0200, Kevin Wolf wrote: >> 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. The docs clearly say that if others feel that there is a conflict with you, they should try to clarify that problem with you directly first. So unless there is someone already repetively complaining about your behavior, just relax, there is nothing to worry about. > I think you need to bear in mind that we're not using some crude AI > to apply blind enforcement of rules. The people responsible for any > enforcement have the ability to apply common sense to situation and so > aren't likely to take action if someone complains about "publishing" an > email address by adding it to a CC on a thread / git commit message. Right. I trust the QEMU leadership committee with their judgement. > If we don't have any CoC then that creates much worse uncertainty because > people who are on the receiving end of bad behaviour will have no idea > whether the QEMU project as a whole even cares about it, or whether it > is the kind of thing that will lead to action being taken, or whom to > talk to about it. Right. That's the point. If someone is really, really misbehaving, we also need a way to show them the door. This is only a last resort, of course, but if someone is really behaving like a complete jerk, we need a way to say: Look, that's not the way how we want to interact with each other in the QEMU community, and if you don't change your attitude, there might be consequences. Thomas
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
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?
On Wed, Mar 31, 2021 at 05:05:27PM +0200, 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. Since this was derived from the Fedora CoC, you might be interested to know that Fedora is currently revisiting its CoC: https://communityblog.fedoraproject.org/policy-proposal-new-code-of-conduct/ The first comment on that post from mattdm gives clarity as to why they feel the need to revisit it Regards, Daniel
Il mar 13 apr 2021, 18:25 Daniel P. Berrangé <berrange@redhat.com> ha scritto: > Since this was derived from the Fedora CoC, you might be interested to > know that Fedora is currently revisiting its CoC: > > > https://communityblog.fedoraproject.org/policy-proposal-new-code-of-conduct/ > > The first comment on that post from mattdm gives clarity as to why they > feel the need to revisit it Interesting, thanks. Indeed the changes that I brought over from the Contributor Covenant (and that were also there, albeit more verbosely, in the Django code of conduct) have the purpose of making the text more specific in case "being excellent to each other" just isn't enough. We also have the separate conflict resolution guide that covers the third point that Matt made in his post. Having some confirmation that those things *were* missing from the current Fedora CoC is good. In fact in the meanwhile I found a few other cases (such as the Microsoft open source code of conduct, https://opensource.microsoft.com/codeofconduct/) that merged a less prescriptive text ultimately derived from Fedora with parts of the Contributor Covenant, so it looks like others have had the same idea in the past. Paolo >
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
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