[scikit-image] Community guidelines

Fri Oct 27 20:42:18 EDT 2017

I have yet to feel that scikit-image needs a CoC, though that does not
necessarily preclude looking into one.  Part of this is helped by keeping
the focus on the code; when we're only talking about how to fix or make the
package better, the path forward clears.  Other issues should fall into the
background.  Even when we disagree, it's with the userbase in mind.  In
brief, I believe the community we build should always be the one we
exemplify, and in the vast majority of cases it could be left there.

My main concern when it comes to this kind of framework, particularly in
the last few years, is about the evolving underlying implications or even
popular meaning of certain phrases or words.  As one example, 'safe
spaces', which the SciPy CoC implies they are creating and shall be
enforcing.  Safe from abuse, spam, harassment, etc.?  Laudable.  Safe *from
dissenting viewpoints*, as it seems has become the more common usage about
some if not many college campuses?  This I do not and will never support.
If my implementation is poor, that needs to be pointed out - everyone
learns and the code gets better.  It takes a certain level of confident
humility to submit your code for review, and there is no way to change
that.  The excellent article 'The Coddling of the American Mind' is more
eloquent than I on this matter:
https://www.theatlantic.com/magazine/archive/2015/09/the-coddling-of-the-american-mind/399356/
.

Related to the above, as political discourse has degenerated over the last
few years I have been alarmed to see names and labels routinely stretched
far outside their true definitions for use as political ammunition.  For
example, it is worth noting that not every Trump supporter is a horrible
sexist racist homophobic Nazi (etc., etc.), but we are constantly being
bombarded by talking heads saying as much.  Within the actual definitions,
including these terms in a CoC is not a problem.  However, if the popular
meanings begin to change, as they arguably already have, they become
problematic in the framework of a CoC that is to be considered akin to a
legal document.

It is also worth noting that my concerns above could be largely addressed
by directly referring to agreed-upon textbook definitions.

Lastly, in any context where you have a true CoC you need to be prepared to
enforce it *to the letter*, or you are better off not having it at all.
This is where most government policy falls down (too many laws, selectively
enforced, everyone's a criminal; the book "Three Felonies A Day"
beautifully illustrates this).  Who does the enforcement?  How and by what
authority?  If us, do we actually have the time to handle it?  Will we
handle it uniformly?  These issues are independent of the Code itself.  As
Juan mentioned, a 3rd party is the standard in many industries and larger
companies, but we don't likely have the funds or need for that.  These
questions should have confident answers, and right now I'm not sure they
do.  Without confident answers, the CoC would be more accurately named
Guidelines of Conduct.

Food for thought.

Josh

On Fri, Oct 27, 2017 at 1:42 PM, Stefan van der Walt <stefanv at berkeley.edu>
wrote:

> Hi, everyone
>
> Thank you for your input, especially François and Matthew who took the
> time to explain opposing views.  I feel one thing we have in this community
> that is precious, and that we should work hard to keep, is that we can have
> friendly conversations on controversial topics.
>
> Part of the reason I have not endorsed any CoCs before (in as much as my
> endorsement is worth anything), is that I was concerned about it stifling
> this type of conversation (or slightly controversial ways of expressing
> your opinion, such as in the SWC case Matthew referred to).  The SciPy CoC
> is the first document that strikes me as taking a big step away from a
> policing focus, while still laying down the ground rules of play.
>
> For let's be clear: *any collaboration has rules, whether they are
> explicit or not*; and I would rather have them be explicit.  We would
> never before have tolerated treating newcomers poorly (you may, e.g., have
> noticed me apologizing to newcomers on GitHub before when I thought
> comments were overly harsh), never mind much worse behavior such as racism
> and sexism.  Putting that down on paper does not change the status quo, but
> as mentioned by others acts as an agreement between all of us to watch out
> for one another, and as a signal to new players as to how we conduct our
> business.
>
> François, I hear your concern about judging others.  And here, I am
> afraid, we will need to trust in the members we appoint to the committee;
> because in the end these issues can be subjective.  In fact, I think we
> should appoint you to that group, if you are willing, to make sure we don't
> step over any lines ;)
>
> A final point: we do not need to accept the document in its current form,
> or at all.  While I think it is a good idea to do that, especially if we
> want to receive sprint funding from groups such as NumFOCUS, the PSF, any
> of numerous foundations, etc., we are not under time pressure, and can take
> time to carefully consider various concerns and objections.
>
> Thank you for taking the time to engage in this conversation, and I look
> forward to hearing any other opinions you all may have.
>
> Best regards
> Stéfan
>
> On Fri, Oct 27, 2017, at 05:28, Matthew Brett wrote:
> > Hi,
> >
> > On Fri, Oct 27, 2017 at 11:09 AM, Juan Nunez-Iglesias
> > <jni.soma at gmail.com> wrote:
> > >
> > >
> > > On 27 Oct 2017, 7:36 PM +1100, François Boulogne <
> fboulogne at sciunto.org>, wrote:
> > >
> > > I feel sad to see that we came to a point that we have to specify such
> policies in a FLOSS community.
> > >
> > >
> > > This is undeniably sad, and, in my experience, it’s come to this due
> to events in other communities, not SciPy. I have not (knowingly) witnessed
> an event where this CoC would have made any difference in the SciPy
> community.
> > >
> > > I have, however, witnessed several instances of more subtle sexism
> that would not be *directly* addressed by the CoC. I expect the same would
> be true of racism. My support from the CoC stems from the belief that it
> signals to underrepresented would-be contributors that we won’t tolerate
> assholes and that they will be treated with respect should they aim to make
> a contribution. This belief is on admittedly shaky ground, but there’s been
> plenty of research to show that female contributors tend to be more
> intimidated by online communities (see e.g. this SO post), so we should do
> what we can to reduce that. Maybe CoC is not the answer but I’d like to be
> doing *something* to change this.
> > >
> > > Moreover, beyond the declaration, I always have doubts
> > > regarding the true efficiency of such guidelines in reality…
> > >
> > >
> > > See above.
> > >
> > > and I’m embarrassed that some of us have the power to judge, when it's
> not their job.
> > >
> > >
> > > “not their job” is a strange thing to object to. All of us are
> volunteering, and the people named on the document have volunteered to be
> so named. (At least, I hope so! ) So, in a way, they’ve made it their job.
> In terms of qualifications, the main question is whether you trust the
> named individuals to be reasonable in their assessments. I’ll admit that I
> don’t know all of them but the ones that I know I 100% would.
> > >
> > > Stéfan in particular has been generally cautious about endorsing CoCs,
> so I trust that he would exercise an abundance of caution in enforcing them.
> > >
> > > This is far from insignificant and could be more harmful than helpful.
> > >
> > >
> > > I’ve seen a lot of fear, uncertainty, and doubt cast over CoCs, but I
> don’t yet know of a case where it has been shown to cause harm?
> >
> > As a contributor to the Scipy code of conduct, I fully share Francois'
> > concerns, while agreeing with much of what you say.
> >
> > I just want to add a couple of things.
> >
> > I humbly beg that we do not refer to anyone, real or imagined, as
> > 'assholes'.   It's an ugly feature of online communities that it seems
> > to be acceptable to give extremely unpleasant labels to people, on
> > subjective grounds, as if we were ourselves infallible in judgment and
> > behavior.   "Troll" is another much-overused and highly subjective
> > word that is very effective for labeling and excluding people.   Yes,
> > we will occasionally be spammed by people with nasty and irrelevant
> > stuff, but that is not a hard situation to deal with.  We wouldn't
> > need these kinds of codes of conduct if that were our only problem.
> >
> > Second - about codes of conduct causing harm.  On that - yes -
> > absolutely - have a read about this incident where a woman was thrown
> > off the Software Carpentry mailing list for some pretty minor
> > misbehavior, and in a cold, formal way [1]. Of course that has a
> > chilling effect on other discussion.  I think the organization got
> > carried away enforcing its code of conduct.
> >
> > But also - codes of conducts are new, we don't know what effect they
> > are going to have.  But I can say, that many of the codes of conducts
> > I have seen, appear to be precisely aimed at 'assholes' - where they
> > deliberately give a lot of space for interpretation of what an
> > 'asshole' is.  That space appears to include being something close to
> > 'rather annoying' or 'a bit unpleasant' [2]. This is a perfect recipe
> > for bullying and exclusion, if anyone felt moved in that direction
> > [3]. There's a reason that our laws don't look like that - otherwise
> > they would be wide open for abuse.  Of course the counter-argument is
> > "Our leader X is awesome, they would never allow that", which, it
> > seems to me, has been adequately refuted by the whole of human
> > history.
> >
> > Cheers,
> >
> > Matthew
> >
> > [1] https://github.com/jupyter/governance/pull/23#issuecomment-269244281
> > [2] https://plus.google.com/u/0/+MatthewBrett/posts/7mQYbw5P7Rc
> > [3] http://kwesthues.com/diffprof.htm
> > _______________________________________________
> > scikit-image mailing list
> > scikit-image at python.org
> > https://mail.python.org/mailman/listinfo/scikit-image
>
>
> _______________________________________________
> scikit-image mailing list
> scikit-image at python.org
> https://mail.python.org/mailman/listinfo/scikit-image
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20171027/c8d91453/attachment-0001.html>