I am more a lurker than a contributor, but I would like to suggest caution with respect to item #5 in the proposed CoC. +5. Be concise. Keep in mind that what you write once will be read by hundreds + of persons. Writing a short email means people can understand the + conversation as efficiently as possible. Short emails should always strive + to be empathetic, welcoming, friendly and patient. When a long explanation + is necessary, consider adding a summary. I suggest that you should stress more that people should strive for clarity and completeness, and then say that brief and comprehensive is the desired goal. I think you're leaning on short too hard, and that will encourage incomplete more than real concision. There are my reasons: 1) one person's concise could well be another's incomplete. 2) There are many, many terms that have more than one use, or that have different meanings in different contexts, or may have connotations; sometimes being concise leads to use of seemingly unambiguous terms that do turn out to be ambiguous. For those who would reply that the definition of 'concise' implies completeness, as in the definition given: giving a lot of information clearly and in a few words; brief but comprehensive. In popular speech, and to those who may have been over-exposed to some kinds of management, concise is more likely to be interpreted as 'abbreviated', which highlights my second point above. I myself often interpret 'concise' to mean 'short' and often 'abbreviated', because that is what I have (alas) become accustomed to in my work environment. Language evolved to have a lot of redundancy built into it for a reason. Stripping it of too much is as bad as including too much. I hope I was sufficiently concise. ;-) On Mon, Oct 2, 2017 at 5:11 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Thu, Sep 14, 2017 at 12:12 AM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Wed, Sep 13, 2017 at 11:39 AM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
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.
Yes - I agree strongly. I think this does do dual service as a statement of values as well as well as a threat of enforcement.
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)
Yes, I like that list a lot. Although, I was proposing in the Jupyter discussion, that informal mediation be triggered really early, to help people get over the feeling of being isolated, that can easily arise in on-line communication - see : https://github.com/jupyter/governance/pull/23#issuecomment-269352416 . This was partly based on my reading of [1] (see quote), which suggested that one reason that women can find online forums intimidating is the lack of a mentor to guide them through the thickets of unfamiliar jargon, habits, and cliques. And partly because, having read that, I realized I felt the same way.
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.
Yes, I agree with that too ... :)
Hi all, here is a new version of the CoC taking this approach: https://github.com/scipy/scipy/pull/7963
Please have a look and comment. Higher level discussion better on this list, detailed textual comments on the PR itself.
Cheers, Ralf
Cheers,
Matthew
[1] https://suegardner.org/2011/02/19/nine-reasons-why-women-dont-edit-wikipedia...
""" The few times I’ve touched wikipedia, I’ve been struck by how isolating it can feel. It’s a very fend for yourself kind of place for me. Anywhere else online, my first impulse is to put out feelers. I make friends, ask for links to FAQs and guides, and inevitably someone takes me under their wing and shows me the ropes of whatever niche culture I’m obsessed with that month. """ _______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev