[SciPy-Dev] establishing a Code of Conduct for SciPy

Mon Oct 2 19:28:38 EDT 2017

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 at gmail.com> wrote:
>
>
> On Thu, Sep 14, 2017 at 12:12 AM, Matthew Brett <matthew.brett at gmail.com>
> wrote:
>>
>> Hi,
>>
>> On Wed, Sep 13, 2017 at 11:39 AM, Ralf Gommers <ralf.gommers at gmail.com>
>> wrote:
>> >
>> >
>> > On Tue, Sep 12, 2017 at 12:08 PM, Stefan van der Walt
>> > <stefanv at 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-in-their-own-words
>>
>> """
>> 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 at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>