[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] docs: Add a QEMU Code of Conduct and Conflict Resolution Pol
From: |
Thomas Huth |
Subject: |
Re: [PATCH] docs: Add a QEMU Code of Conduct and Conflict Resolution Policy document |
Date: |
Tue, 30 Mar 2021 09:13:56 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 |
On 29/03/2021 22.59, Paolo Bonzini wrote:
Il lun 29 mar 2021, 20:33 Daniel P. Berrangé <berrange@redhat.com
<mailto:berrange@redhat.com>> ha scritto:
The obvious alternative is to import the contributor covenant
https://www.contributor-covenant.org/
<https://www.contributor-covenant.org/>
The Contributor Covenant 1.x and 2.x are very different in that 2.x also
includes conflict resolution. Unlike the code of conduct, the consequences
of bad behavior are hard to generalize across multiple projects, so I would
prefer anyway the 1.x version. The differences with the Django CoC aren't
substantial.
Right. I also think we should use a code of conduct that allows us to keep
the conflict resolution in a separate document.
Contributor Covenant 1.x is certainly an option, too, but it has IMHO
already quite rigorous language ("Project maintainers have the [...]
responsibility to remove, edit, or reject comments, commits, code, wiki
edits ...", "Project maintainers who do not [...] enforce the Code of
Conduct may be permanently removed from the project team."), which could
either scare away people from taking maintainers responsibility or also
could be used fire up arguments ("you are a maintainer, now according to the
CoC you have to do this and that..."), which I'd rather like to avoid.
(well, as you know, I'm not a native English speaker, so I might also have
gotten that tone wrong, but that's the impression that I had after reading
that text as non-native speaker).
That's why I'd rather prefer the Django CoC instead.
However this does mean being more careful about the language in the "custom"
documents such as the conflict resolution policy.
The second, it isn't a static document. It is being evolved over
time with new versions issued as understanding of problematic
situations evolves. We can choose to periodically update to stay
current with the broadly accepted norms.
This however has the same issues as the "or later" clause of the GPL (see
the above example of 1.x vs 2.x for the Contributor Covenant). I don't think
upgrade of the CoC should be automatic since there are no "compatibility"
issues.
Agreed. We shouldn't auto-upgrade to a newer version of a CoC without
reviewing the new clauses.
> +If you are experiencing conflict, you should first address the perceived
> +conflict directly with other involved parties, preferably through a
> +real-time medium such as IRC. If this fails,
I agree with Daniel that this part should only be advisory. For example:
If you are experiencing conflict, please consider first addressing the
perceived conflict directly with other involved parties, preferably through
a real-time medium such as IRC. If this fails or if you do not feel
comfortable proceeding this way,...
Also this document doesn't mention anything about ensuring the
confidentiality/privacy for any complaints reported, which I
think is important to state explicitly.
Agreed, and also the part about keeping a record should be removed from the
consequences part because it's a privacy regulation minefield.
Ok, thanks for the feedback, I'll try to incorporate it and send a v2.
Thomas