On Tue, Sep 12, 2017 at 12:08 PM, Stefan van der Walt <stefanv@berkeley.edu> wrote:
On Mon, Sep 11, 2017, at 14:08, Pauli Virtanen wrote:
It can of course be useful to think about writing such things down explicitly to produce a document explaining (1), and I think the Apache one gives good hints for keeping things productive. But it is less clear to me this is something for which formal moderator action would be necessary.
However, if I understand correctly, the reason why people want these things is more about (2). Indeed, this is standard stuff in the workplace and in moderation of internet forums (usually in "Rules" in the latter).
Agreed that many people want it for (2). There's an important difference though. Forum rules and workplace policies are usually not very visible, while with a CoC for an open source project one wants it to be quite visible. Therefore the importance of it having a positive tone and statements about what we value is a lot more important than for something like a workplace policy. It seems a good idea to structure this part so that it
does not fail if someone acts in bad faith, and so that the moderation plan is reasonable to the reader and possible to implement.
I feel it is important to mix in a bit of (1) with (2), the reason being that almost every person reading the CoC will not ever act in bad faith. You'd think that those people could simply ignore language related to enforcement, but in previous discussions (e.g., around the Jupyter CoC) that turned out not to be the case: it is all too easy to frighten people into not speaking up.
So, I'd recommend focusing on a description of the kind of community we want, instead of what we're trying to avoid; and postponing the enforcement language until later in the document, making it clear that enforcement only comes through (somewhat wide) deliberation of trusted community members (and, preferably, also after engagement with the offending party).
This way, we can hopefully instill trust in our CoC as a process, rather than a set of rules.
That sounds quite good to me. The process at a high level (for all but the most severe cases) should be something like: 1. complaint 2. reasonable discussion/feedback 3. mediation (if feedback didn't help) 4. enforcement via transparent decision by CoC committee (if mediation failed) And not what some people may be afraid of, and sometimes actually happens in practice: 1. complaint 2. enforcement For a new CoC draft, taking most of the Apache doc and tacking the more rules/enforcement oriented content of the Contributor Covenant onto the end seems like a good starting point. Ralf