From jni.soma at gmail.com  Wed Oct  4 01:51:14 2017
From: jni.soma at gmail.com (Juan Nunez-Iglesias)
Date: Wed, 4 Oct 2017 16:51:14 +1100
Subject: [scikit-image]
 =?utf-8?Q?=E5=9B=9E=E5=A4=8D=EF=BC=9ARe=3A__?=Code for the short course
 'Image Processing using Python', @ IAMG2017
In-Reply-To: <15ea55aa618.2815.acf34a9c767d7bb498a799333be0433e@fastmail.com>
References: <20170921061939.DEABF400FA@webmail.sinamail.sina.com.cn>
 <9373f9f9-2ee5-4b0b-ad73-dd8304aea6ec@Spark>
 <1505977180.840036.1113324136.64FB1DB7@webmail.messagingengine.com>
 <8ac1190f-24e1-4636-a1b4-2bc5c1e0e613@Spark>
 <15ea55aa618.2815.acf34a9c767d7bb498a799333be0433e@fastmail.com>
Message-ID: <24858fdd-adcf-4fa7-adc6-212d2ea43129@Spark>

Hi Yan, (et al)

The new license is now merged into the repo. Please see the README here:

https://github.com/scikit-image/skimage-tutorials/#usage

Juan.

On 22 Sep 2017, 2:52 AM +1000, Stefan van der Walt <stefanv at berkeley.edu>, wrote:
> On 21 September 2017 00:18:05 Juan Nunez-Iglesias <jni.soma at gmail.com> wrote:
> > On 21 Sep 2017, 5:00 PM +1000, Stefan van der Walt <stefanv at berkeley.edu>, wrote:
> >
> >> Thanks, I never noticed! ?All the lessons were contributed for teaching purposes, so I don't imagine adding a license now would be a problem. ?CC-BY is fine, although we should also consider CC-0.
> >
> > Sure. How about CC0 + adding a note in the readme, ?if you find these tutorials useful, we appreciate mentioning them in any derivative works.?
> That works, thanks!
> St?fan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20171004/07dc9009/attachment.html>

From siqueiraaf at gmail.com  Thu Oct  5 09:22:39 2017
From: siqueiraaf at gmail.com (Alexandre Fioravante de Siqueira)
Date: Thu, 5 Oct 2017 10:22:39 -0300
Subject: [scikit-image] Using the flooding watershed
Message-ID: <CANPz1oZoVDdbEoOz4V5QCwQpAjwt5v_XjNHAokTv_kmFDKwYkA@mail.gmail.com>

Dear all,
I am trying to write a that mimics the behavior of ImageJ's flooding
watershed. This is how they describe it (
https://imagej.nih.gov/ij/docs/menus/process.html#watershed):


*Watershed*

*Watershed segmentation is a way of automatically separating or cutting
apart particles that touch. It first calculates the Euclidian distance map
(EDM) and finds the ultimate eroded points (UEPs). It then dilates each of
the UEPs (the peaks or local maxima of the EDM) as far as possible - either
until the edge of the particle is reached, or the edge of the region of
another (growing) UEP. Watershed segmentation works best for smooth convex
objects that don't overlap too much.*

I tried to implement that (more or less), using the local minima (as
pointed in https://www.mathworks.com/help/images/ref/bwulterode.html). Of
course, there is something wrong :)

from scipy.ndimage import binary_fill_holes
from scipy.ndimage.morphology import distance_transform_edt
from skimage.feature import peak_local_max
from skimage.filters import threshold_otsu
from skimage.io import imread
from skimage.measure import label
from skimage.morphology import disk, watershed
from skimage.util import invert

import matplotlib.pyplot as plt

image = imread('K90_incid4,5min_1.bmp')
img_bin = binary_fill_holes(image < threshold_otsu(image))

inv_bin = invert(img_bin)
inv_dist = distance_transform_edt(inv_bin)
inv_peak = peak_local_max(-inv_dist, indices=False)
markers = label(peak)
labels = watershed(-distance, markers, mask=img_bin, watershed_line=True)

plt.imshow(labels, cmap='nipy_spectral'), plt.show()

We don't have a function for UEPs in skimage yet, right?
How could I implement this flooding watershed?
Thank you very much. Kind regards,

Alex

-- 
--------------------------------------------------
Dr. Alexandre 'Jaguar' Fioravante de Siqueira
Grupo de Cronologia - Sala 13
Departamento de Raios C?smicos e Cronologia - DRCC
Instituto de F?sica "Gleb Wataghin" - IFGW
Unicamp - Universidade Estadual de Campinas
Rua S?rgio Buarque de Holanda, 777
Cidade Universit?ria Zeferino Vaz - CEP 13083-859
Campinas - SP - Brazil

Phone: +55(19)3521-5362
Lattes curriculum: 3936721630855880
<http://lattes.cnpq.br/3936721630855880/>
ORCID: 0000-0003-1320-4347 <http://orcid.org/0000-0003-1320-4347>
Personal site: programmingscience.org <http://www.programmingscience.org/>
Github: alexandrejaguar <http://www.github.com/alexandrejaguar/>
Skype: alexandrejaguar
Twitter: alexdesiqueira <http://www.twitter.com/alexdesiqueira/>
--------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20171005/b9a720e5/attachment.html>

From Thomas.Edgar.Walter at googlemail.com  Thu Oct  5 09:41:18 2017
From: Thomas.Edgar.Walter at googlemail.com (Thomas Walter)
Date: Thu, 5 Oct 2017 15:41:18 +0200
Subject: [scikit-image] Using the flooding watershed
In-Reply-To: <CANPz1oZoVDdbEoOz4V5QCwQpAjwt5v_XjNHAokTv_kmFDKwYkA@mail.gmail.com>
References: <CANPz1oZoVDdbEoOz4V5QCwQpAjwt5v_XjNHAokTv_kmFDKwYkA@mail.gmail.com>
Message-ID: <7509c906-64c8-2898-f9d6-fddb298fb67a@googlemail.com>

Hello Alex,

the ultimate erosion coincides with the local maxima of the distance map 
(or the local minima of the inverse distance map).

In skimage, you can get these by:

from skimage.morphology import extrema local_maxima  =  extrema.local_maxima 
<http://scikit-image.org/docs/dev/api/skimage.morphology.html#skimage.morphology.local_maxima>(distance_map)


peak_local_max is not equivalent to the UEP, but can be preferable in 
certain situations.

I did not check your example in practice as I do not have the image, but 
I was a bit confused by the inversions, as you start by applying the 
threshold the other way around.

Best,

Thomas.

P.S.: The ImageJ description is not correct, which I have always found 
disturbing. The Watershed algorithm is of course not limited to 
applications to the inverse distance map.


On 10/5/17 3:22 PM, Alexandre Fioravante de Siqueira wrote:
> Dear all,
> I am trying to write a that mimics the behavior of ImageJ's flooding 
> watershed. This is how they describe it 
> (https://imagej.nih.gov/ij/docs/menus/process.html#watershed):
>
> /Watershed
> /
> /Watershed segmentation is a way of automatically separating or 
> cutting apart particles that touch. It first calculates the Euclidian 
> distance map (EDM) and finds the ultimate eroded points (UEPs). It 
> then dilates each of the UEPs (the peaks or local maxima of the EDM) 
> as far as possible - either until the edge of the particle is reached, 
> or the edge of the region of another (growing) UEP. Watershed 
> segmentation works best for smooth convex objects that don't overlap 
> too much.
> /
>
> I tried to implement that (more or less), using the local minima (as 
> pointed in https://www.mathworks.com/help/images/ref/bwulterode.html). 
> Of course, there is something wrong :)
>
> from scipy.ndimage import binary_fill_holes
> from scipy.ndimage.morphology import distance_transform_edt
> from skimage.feature import peak_local_max
> from skimage.filters import threshold_otsu
> from skimage.io <http://skimage.io> import imread
> from skimage.measure import label
> from skimage.morphology import disk, watershed
> from skimage.util import invert
>
> import matplotlib.pyplot as plt
>
> image = imread('K90_incid4,5min_1.bmp')
> img_bin = binary_fill_holes(image < threshold_otsu(image))
>
> inv_bin = invert(img_bin)
> inv_dist = distance_transform_edt(inv_bin)
> inv_peak = peak_local_max(-inv_dist, indices=False)
> markers = label(peak)
> labels = watershed(-distance, markers, mask=img_bin, watershed_line=True)
>
> plt.imshow(labels, cmap='nipy_spectral'), plt.show()
>
> We don't have a function for UEPs in skimage yet, right?
> How could I implement this flooding watershed?
> Thank you very much. Kind regards,
>
> Alex
>
> -- 
> --------------------------------------------------
> Dr. Alexandre 'Jaguar' Fioravante de Siqueira
> Grupo de Cronologia - Sala 13
> Departamento de Raios C?smicos e Cronologia - DRCC
> Instituto de F?sica "Gleb Wataghin" - IFGW
> Unicamp - Universidade Estadual de Campinas
> Rua S?rgio Buarque de Holanda, 777
> Cidade Universit?ria Zeferino Vaz - CEP 13083-859
> Campinas - SP - Brazil
>
> Phone: +55(19)3521-5362
> Lattes curriculum: 3936721630855880 
> <http://lattes.cnpq.br/3936721630855880/>
> ORCID: 0000-0003-1320-4347 <http://orcid.org/0000-0003-1320-4347>
> Personal site: programmingscience.org <http://www.programmingscience.org/>
> Github: alexandrejaguar <http://www.github.com/alexandrejaguar/>
> Skype: alexandrejaguar
> Twitter: alexdesiqueira <http://www.twitter.com/alexdesiqueira/>
> --------------------------------------------------
>
>
> _______________________________________________
> scikit-image mailing list
> scikit-image at python.org
> https://mail.python.org/mailman/listinfo/scikit-image


-- 
Thomas Walter
27 rue des Acacias
75017 Paris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20171005/121b4825/attachment-0001.html>

From siqueiraaf at gmail.com  Thu Oct  5 10:06:45 2017
From: siqueiraaf at gmail.com (Alexandre Fioravante de Siqueira)
Date: Thu, 5 Oct 2017 11:06:45 -0300
Subject: [scikit-image] scikit-image Digest, Vol 13, Issue 2
In-Reply-To: <mailman.1236.1507212012.2818.scikit-image@python.org>
References: <mailman.1236.1507212012.2818.scikit-image@python.org>
Message-ID: <CANPz1oY-PUu5X6BvHDBEmGgeErE=E-+zYZW+qewzmmyNhRn65A@mail.gmail.com>

Hi all,
Thomas, thank you for your help, and sorry for not sending the image. It
follows attached.
I applied the threshold that way because I'm interested in the "black
spots" in the image.
Thank you again. I'll try to run the code using your insights.
Kind regards,

Alex

PS.: Could you tell a little more about the errors in ImageJ's description?
Thank you for that!

On Thu, Oct 5, 2017 at 11:00 AM, <scikit-image-request at python.org> wrote:

> Send scikit-image mailing list submissions to
>         scikit-image at python.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://mail.python.org/mailman/listinfo/scikit-image
> or, via email, send a message with subject or body 'help' to
>         scikit-image-request at python.org
>
> You can reach the person managing the list at
>         scikit-image-owner at python.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of scikit-image digest..."
>
> Today's Topics:
>
>    1. Using the flooding watershed (Alexandre Fioravante de Siqueira)
>    2. Re: Using the flooding watershed (Thomas Walter)
>
>
> ---------- Forwarded message ----------
> From: Alexandre Fioravante de Siqueira <siqueiraaf at gmail.com>
> To: scikit-image at python.org
> Cc:
> Bcc:
> Date: Thu, 5 Oct 2017 10:22:39 -0300
> Subject: [scikit-image] Using the flooding watershed
> Dear all,
> I am trying to write a that mimics the behavior of ImageJ's flooding
> watershed. This is how they describe it (https://imagej.nih.gov/ij/
> docs/menus/process.html#watershed):
>
>
> *Watershed*
>
> *Watershed segmentation is a way of automatically separating or cutting
> apart particles that touch. It first calculates the Euclidian distance map
> (EDM) and finds the ultimate eroded points (UEPs). It then dilates each of
> the UEPs (the peaks or local maxima of the EDM) as far as possible - either
> until the edge of the particle is reached, or the edge of the region of
> another (growing) UEP. Watershed segmentation works best for smooth convex
> objects that don't overlap too much.*
>
> I tried to implement that (more or less), using the local minima (as
> pointed in https://www.mathworks.com/help/images/ref/bwulterode.html). Of
> course, there is something wrong :)
>
> from scipy.ndimage import binary_fill_holes
> from scipy.ndimage.morphology import distance_transform_edt
> from skimage.feature import peak_local_max
> from skimage.filters import threshold_otsu
> from skimage.io import imread
> from skimage.measure import label
> from skimage.morphology import disk, watershed
> from skimage.util import invert
>
> import matplotlib.pyplot as plt
>
> image = imread('K90_incid4,5min_1.bmp')
> img_bin = binary_fill_holes(image < threshold_otsu(image))
>
> inv_bin = invert(img_bin)
> inv_dist = distance_transform_edt(inv_bin)
> inv_peak = peak_local_max(-inv_dist, indices=False)
> markers = label(peak)
> labels = watershed(-distance, markers, mask=img_bin, watershed_line=True)
>
> plt.imshow(labels, cmap='nipy_spectral'), plt.show()
>
> We don't have a function for UEPs in skimage yet, right?
> How could I implement this flooding watershed?
> Thank you very much. Kind regards,
>
> Alex
>
> --
> --------------------------------------------------
> Dr. Alexandre 'Jaguar' Fioravante de Siqueira
> Grupo de Cronologia - Sala 13
> Departamento de Raios C?smicos e Cronologia - DRCC
> Instituto de F?sica "Gleb Wataghin" - IFGW
> Unicamp - Universidade Estadual de Campinas
> Rua S?rgio Buarque de Holanda, 777
> Cidade Universit?ria Zeferino Vaz - CEP 13083-859
> Campinas - SP - Brazil
>
> Phone: +55(19)3521-5362 <+55%2019%203521-5362>
> Lattes curriculum: 3936721630855880
> <http://lattes.cnpq.br/3936721630855880/>
> ORCID: 0000-0003-1320-4347 <http://orcid.org/0000-0003-1320-4347>
> Personal site: programmingscience.org <http://www.programmingscience.org/>
> Github: alexandrejaguar <http://www.github.com/alexandrejaguar/>
> Skype: alexandrejaguar
> Twitter: alexdesiqueira <http://www.twitter.com/alexdesiqueira/>
> --------------------------------------------------
>
>
> ---------- Forwarded message ----------
> From: Thomas Walter <Thomas.Edgar.Walter at googlemail.com>
> To: scikit-image at python.org
> Cc:
> Bcc:
> Date: Thu, 5 Oct 2017 15:41:18 +0200
> Subject: Re: [scikit-image] Using the flooding watershed
> Hello Alex,
>
> the ultimate erosion coincides with the local maxima of the distance map
> (or the local minima of the inverse distance map).
>
> In skimage, you can get these by:
>
> from skimage.morphology import extremalocal_maxima = extrema.local_maxima <http://scikit-image.org/docs/dev/api/skimage.morphology.html#skimage.morphology.local_maxima>(distance_map)
>
>
> peak_local_max is not equivalent to the UEP, but can be preferable in
> certain situations.
>
> I did not check your example in practice as I do not have the image, but I
> was a bit confused by the inversions, as you start by applying the
> threshold the other way around.
>
> Best,
>
> Thomas.
>
> P.S.: The ImageJ description is not correct, which I have always found
> disturbing. The Watershed algorithm is of course not limited to
> applications to the inverse distance map.
>
>
> On 10/5/17 3:22 PM, Alexandre Fioravante de Siqueira wrote:
>
> Dear all,
> I am trying to write a that mimics the behavior of ImageJ's flooding
> watershed. This is how they describe it (https://imagej.nih.gov/ij/
> docs/menus/process.html#watershed):
>
>
> *Watershed *
>
> *Watershed segmentation is a way of automatically separating or cutting
> apart particles that touch. It first calculates the Euclidian distance map
> (EDM) and finds the ultimate eroded points (UEPs). It then dilates each of
> the UEPs (the peaks or local maxima of the EDM) as far as possible - either
> until the edge of the particle is reached, or the edge of the region of
> another (growing) UEP. Watershed segmentation works best for smooth convex
> objects that don't overlap too much. *
>
> I tried to implement that (more or less), using the local minima (as
> pointed in https://www.mathworks.com/help/images/ref/bwulterode.html). Of
> course, there is something wrong :)
>
> from scipy.ndimage import binary_fill_holes
> from scipy.ndimage.morphology import distance_transform_edt
> from skimage.feature import peak_local_max
> from skimage.filters import threshold_otsu
> from skimage.io import imread
> from skimage.measure import label
> from skimage.morphology import disk, watershed
> from skimage.util import invert
>
> import matplotlib.pyplot as plt
>
> image = imread('K90_incid4,5min_1.bmp')
> img_bin = binary_fill_holes(image < threshold_otsu(image))
>
> inv_bin = invert(img_bin)
> inv_dist = distance_transform_edt(inv_bin)
> inv_peak = peak_local_max(-inv_dist, indices=False)
> markers = label(peak)
> labels = watershed(-distance, markers, mask=img_bin, watershed_line=True)
>
> plt.imshow(labels, cmap='nipy_spectral'), plt.show()
>
> We don't have a function for UEPs in skimage yet, right?
> How could I implement this flooding watershed?
> Thank you very much. Kind regards,
>
> Alex
>
> --
> --------------------------------------------------
> Dr. Alexandre 'Jaguar' Fioravante de Siqueira
> Grupo de Cronologia - Sala 13
> Departamento de Raios C?smicos e Cronologia - DRCC
> Instituto de F?sica "Gleb Wataghin" - IFGW
> Unicamp - Universidade Estadual de Campinas
> Rua S?rgio Buarque de Holanda, 777
> Cidade Universit?ria Zeferino Vaz - CEP 13083-859
> Campinas - SP - Brazil
>
> Phone: +55(19)3521-5362 <+55%2019%203521-5362>
> Lattes curriculum: 3936721630855880
> <http://lattes.cnpq.br/3936721630855880/>
> ORCID: 0000-0003-1320-4347 <http://orcid.org/0000-0003-1320-4347>
> Personal site: programmingscience.org <http://www.programmingscience.org/>
> Github: alexandrejaguar <http://www.github.com/alexandrejaguar/>
> Skype: alexandrejaguar
> Twitter: alexdesiqueira <http://www.twitter.com/alexdesiqueira/>
> --------------------------------------------------
>
>
> _______________________________________________
> scikit-image mailing listscikit-image at python.orghttps://mail.python.org/mailman/listinfo/scikit-image
>
>
>
> --
> Thomas Walter
> 27 rue des Acacias
> 75017 Paris
>
>
> _______________________________________________
> scikit-image mailing list
> scikit-image at python.org
> https://mail.python.org/mailman/listinfo/scikit-image
>
>


-- 
--------------------------------------------------
Dr. Alexandre 'Jaguar' Fioravante de Siqueira
Grupo de Cronologia - Sala 13
Departamento de Raios C?smicos e Cronologia - DRCC
Instituto de F?sica "Gleb Wataghin" - IFGW
Unicamp - Universidade Estadual de Campinas
Rua S?rgio Buarque de Holanda, 777
Cidade Universit?ria Zeferino Vaz - CEP 13083-859
Campinas - SP - Brazil

Phone: +55(19)3521-5362
Lattes curriculum: 3936721630855880
<http://lattes.cnpq.br/3936721630855880/>
ORCID: 0000-0003-1320-4347 <http://orcid.org/0000-0003-1320-4347>
Personal site: programmingscience.org <http://www.programmingscience.org/>
Github: alexandrejaguar <http://www.github.com/alexandrejaguar/>
Skype: alexandrejaguar
Twitter: alexdesiqueira <http://www.twitter.com/alexdesiqueira/>
--------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20171005/b3cfe4ca/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: K90_incid4,5min_1.bmp
Type: image/bmp
Size: 441910 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20171005/b3cfe4ca/attachment-0001.bin>

From jni.soma at gmail.com  Sun Oct  8 22:17:14 2017
From: jni.soma at gmail.com (Juan Nunez-Iglesias)
Date: Mon, 9 Oct 2017 13:17:14 +1100
Subject: [scikit-image] Using the flooding watershed
In-Reply-To: <7509c906-64c8-2898-f9d6-fddb298fb67a@googlemail.com>
References: <CANPz1oZoVDdbEoOz4V5QCwQpAjwt5v_XjNHAokTv_kmFDKwYkA@mail.gmail.com>
 <7509c906-64c8-2898-f9d6-fddb298fb67a@googlemail.com>
Message-ID: <4fec0434-3bd5-4ec1-b825-91c1e003dcfd@Spark>

Hey Alex,

Do an imshow on your distance transform, ie `inv_dist`. You?ll see that it?s incorrect ? it has the peaks outside of the bubbles. Then inv_peak has as the ?maxima? the entire bubble ? not good! So you should run your distance transform on `img_bin` rather than `inv_bin` and I think it?ll be a better result!

Juan.

On 6 Oct 2017, 1:00 AM +1100, Thomas Walter via scikit-image <scikit-image at python.org>, wrote:
> Hello Alex,
>
> the ultimate erosion coincides with the local maxima of the distance map (or the local minima of the inverse distance map).
>
> In skimage, you can get these by:
>
> from skimage.morphology import extrema
> local_maxima = extrema.local_maxima(distance_map)
>
> peak_local_max is not equivalent to the UEP, but can be preferable in certain situations.
>
> I did not check your example in practice as I do not have the image, but I was a bit confused by the inversions, as you start by applying the threshold the other way around.
>
> Best,
>
> Thomas.
>
> P.S.: The ImageJ description is not correct, which I have always found disturbing. The Watershed algorithm is of course not limited to applications to the inverse distance map.
>
>
> On 10/5/17 3:22 PM, Alexandre Fioravante de Siqueira wrote:
> > Dear all,
> > I am trying to write a that mimics the behavior of ImageJ's flooding watershed. This is how they describe it (https://imagej.nih.gov/ij/docs/menus/process.html#watershed):
> >
> > Watershed
> > Watershed segmentation is a way of automatically separating or cutting apart particles that touch. It first calculates the Euclidian distance map (EDM) and finds the ultimate eroded points (UEPs). It then dilates each of the UEPs (the peaks or local maxima of the EDM) as far as possible - either until the edge of the particle is reached, or the edge of the region of another (growing) UEP. Watershed segmentation works best for smooth convex objects that don't overlap too much.
> >
> > I tried to implement that (more or less), using the local minima (as pointed in?https://www.mathworks.com/help/images/ref/bwulterode.html). Of course, there is something wrong :)
> >
> > from scipy.ndimage import binary_fill_holes
> > from scipy.ndimage.morphology import distance_transform_edt
> > from skimage.feature import peak_local_max
> > from skimage.filters import threshold_otsu
> > from skimage.io import imread
> > from skimage.measure import label
> > from skimage.morphology import disk, watershed
> > from skimage.util import invert
> >
> > import matplotlib.pyplot as plt
> >
> > image = imread('K90_incid4,5min_1.bmp')
> > img_bin = binary_fill_holes(image < threshold_otsu(image))
> >
> > inv_bin = invert(img_bin)
> > inv_dist = distance_transform_edt(inv_bin)
> > inv_peak = peak_local_max(-inv_dist, indices=False)
> > markers = label(peak)
> > labels = watershed(-distance, markers, mask=img_bin, watershed_line=True)
> >
> > plt.imshow(labels, cmap='nipy_spectral'), plt.show()
> >
> > We don't have a function for UEPs in skimage yet, right?
> > How could I implement this flooding watershed?
> > Thank you very much. Kind regards,
> >
> > Alex
> >
> > --
> > --------------------------------------------------
> > Dr. Alexandre 'Jaguar' Fioravante de Siqueira
> > Grupo de Cronologia - Sala 13
> > Departamento de Raios C?smicos e Cronologia - DRCC
> > Instituto de F?sica "Gleb Wataghin" - IFGW
> > Unicamp - Universidade Estadual de Campinas
> > Rua S?rgio Buarque de Holanda, 777
> > Cidade Universit?ria Zeferino Vaz - CEP 13083-859
> > Campinas - SP - Brazil
> >
> > Phone: +55(19)3521-5362
> > Lattes curriculum: 3936721630855880
> > ORCID:?0000-0003-1320-4347
> > Personal site: programmingscience.org
> > Github: alexandrejaguar
> > Skype: alexandrejaguar
> > Twitter: alexdesiqueira
> > --------------------------------------------------
> >
> >
> > _______________________________________________
> > scikit-image mailing list
> > scikit-image at python.org
> > https://mail.python.org/mailman/listinfo/scikit-image
>
>
> --
> Thomas Walter
> 27 rue des Acacias
> 75017 Paris
> _______________________________________________
> 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/20171009/2178a632/attachment.html>

From pskeshu at gmail.com  Fri Oct 13 02:49:12 2017
From: pskeshu at gmail.com (Kesavan Subburam)
Date: Fri, 13 Oct 2017 12:19:12 +0530
Subject: [scikit-image] Removing interference pattern noise
Message-ID: <CAEyWfbFZ55DSzc04AGo9+dYmDcYi_C34rPvbxCNZJkocDqgHfg@mail.gmail.com>

Hi all,

I'm trying to remove interference pattern noise from my optics in my data,
and to that effect, I have imaged the pattern by capturing an image without
any sample (pattern.jpg). I was wondering what would be the straight
forward way to remove such pattern noise. I don't suppose a simple
subtraction would suffice.

I have attached a sample image here. I have compressed it because of the
mailing list limitations on file sizes.


Thank you,

-- 
Kesavan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20171013/3a482eb8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: data.jpg
Type: image/jpeg
Size: 188091 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20171013/3a482eb8/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pattern.jpg
Type: image/jpeg
Size: 188734 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20171013/3a482eb8/attachment-0003.jpg>

From imaluengo at gmail.com  Fri Oct 13 03:28:14 2017
From: imaluengo at gmail.com (=?UTF-8?Q?Imanol_Luengo_Munti=C3=B3n?=)
Date: Fri, 13 Oct 2017 08:28:14 +0100
Subject: [scikit-image] Removing interference pattern noise
In-Reply-To: <CAEyWfbFZ55DSzc04AGo9+dYmDcYi_C34rPvbxCNZJkocDqgHfg@mail.gmail.com>
References: <CAEyWfbFZ55DSzc04AGo9+dYmDcYi_C34rPvbxCNZJkocDqgHfg@mail.gmail.com>
Message-ID: <CAM4udr6Bs=_-WGaQLc2uNbciObYxpN0H+16GHBt2z-q7Ou33yA@mail.gmail.com>

Hi Kesavan,

I believe your problem is called flat field correction:

https://en.m.wikipedia.org/wiki/Flat-field_correction

Not sure if scikit-image has something already implemented, but the formula
is simple and shouldn't be too complicated.

Best,
Imanol

On Oct 13, 2017 8:17 AM, "Kesavan Subburam" <pskeshu at gmail.com> wrote:

Hi all,

I'm trying to remove interference pattern noise from my optics in my data,
and to that effect, I have imaged the pattern by capturing an image without
any sample (pattern.jpg). I was wondering what would be the straight
forward way to remove such pattern noise. I don't suppose a simple
subtraction would suffice.

I have attached a sample image here. I have compressed it because of the
mailing list limitations on file sizes.


Thank you,

-- 
Kesavan

_______________________________________________
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/20171013/c5d9b82c/attachment.html>

From stefanv at berkeley.edu  Tue Oct 24 14:32:53 2017
From: stefanv at berkeley.edu (Stefan van der Walt)
Date: Tue, 24 Oct 2017 11:32:53 -0700
Subject: [scikit-image] Community guidelines
Message-ID: <1508869973.2082990.1149621008.4442203C@webmail.messagingengine.com>

Hi, everyone

SciPy just merged their Code of Conduct documents after a long
discussion [0]:

https://github.com/scipy/scipy/blob/master/doc/source/dev/conduct/code_of_conduct.rst
https://github.com/scipy/scipy/blob/master/doc/source/dev/conduct/report_handling_manual.rst

I have been hesitant to include anything similar for scikit-image before
(other than http://scikit-image.org/community_guidelines.html ), because
I did not feel comfortable with the aloof policing tone typically
employed in similar documents elsewhere.

But, I think the SciPy documents make an important statement about our
vision for an inclusive community, and does so in a friendly but serious
way.

How would you feel about adopting these documents for scikit-image?

Best regards
St?fan

[0]: https://github.com/scipy/scipy/pull/7963

From jni.soma at gmail.com  Wed Oct 25 04:58:00 2017
From: jni.soma at gmail.com (Juan Nunez-Iglesias)
Date: Wed, 25 Oct 2017 19:58:00 +1100
Subject: [scikit-image] Community guidelines
In-Reply-To: <1508869973.2082990.1149621008.4442203C@webmail.messagingengine.com>
References: <1508869973.2082990.1149621008.4442203C@webmail.messagingengine.com>
Message-ID: <a8228e3c-e463-4b1f-aaaa-4e04c0ecbc7b@Spark>

+1 from me. I specifically like having external people to report incidents to.

Juan.

On 25 Oct 2017, 5:33 AM +1100, Stefan van der Walt <stefanv at berkeley.edu>, wrote:
> Hi, everyone
>
> SciPy just merged their Code of Conduct documents after a long
> discussion [0]:
>
> https://github.com/scipy/scipy/blob/master/doc/source/dev/conduct/code_of_conduct.rst
> https://github.com/scipy/scipy/blob/master/doc/source/dev/conduct/report_handling_manual.rst
>
> I have been hesitant to include anything similar for scikit-image before
> (other than http://scikit-image.org/community_guidelines.html ), because
> I did not feel comfortable with the aloof policing tone typically
> employed in similar documents elsewhere.
>
> But, I think the SciPy documents make an important statement about our
> vision for an inclusive community, and does so in a friendly but serious
> way.
>
> How would you feel about adopting these documents for scikit-image?
>
> Best regards
> St?fan
>
> [0]: https://github.com/scipy/scipy/pull/7963
> _______________________________________________
> 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/20171025/cc470f11/attachment.html>

From stefanv at berkeley.edu  Thu Oct 26 00:21:36 2017
From: stefanv at berkeley.edu (Stefan van der Walt)
Date: Wed, 25 Oct 2017 21:21:36 -0700
Subject: [scikit-image] Community guidelines
In-Reply-To: <a8228e3c-e463-4b1f-aaaa-4e04c0ecbc7b@Spark>
References: <1508869973.2082990.1149621008.4442203C@webmail.messagingengine.com>
 <a8228e3c-e463-4b1f-aaaa-4e04c0ecbc7b@Spark>
Message-ID: <1508991696.2533515.1151368096.2D42891C@webmail.messagingengine.com>

Thanks for letting me know, Juan.

I'd also like to hear from the rest of the community---what are
your thoughts?
St?fan

On Wed, Oct 25, 2017, at 01:58, Juan Nunez-Iglesias wrote:
> +1 from me. I specifically like having external people to report
> incidents to.> 
> Juan.
> 
> On 25 Oct 2017, 5:33 AM +1100, Stefan van der Walt
> <stefanv at berkeley.edu>, wrote:> 
>> Hi, everyone
>> 
>>  SciPy just merged their Code of Conduct documents after a long
>>  discussion [0]:
>> 
>>  https://github.com/scipy/scipy/blob/master/doc/source/dev/conduct/code_of_conduct.rst>>  https://github.com/scipy/scipy/blob/master/doc/source/dev/conduct/report_handling_manual.rst>> 
>>  I have been hesitant to include anything similar for scikit-image
>>  before>>  (other than http://scikit-image.org/community_guidelines.html ),
>>  because>>  I did not feel comfortable with the aloof policing tone typically
>>  employed in similar documents elsewhere.
>> 
>>  But, I think the SciPy documents make an important statement
>>  about our>>  vision for an inclusive community, and does so in a friendly but
>>  serious>>  way.
>> 
>>  How would you feel about adopting these documents for scikit-image?>> 
>>  Best regards
>>  St?fan
>> 
>>  [0]: https://github.com/scipy/scipy/pull/7963
>>  _______________________________________________
>>  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/20171025/cfd2120a/attachment.html>

From steven.silvester at gmail.com  Thu Oct 26 05:58:38 2017
From: steven.silvester at gmail.com (Steven Silvester)
Date: Thu, 26 Oct 2017 04:58:38 -0500
Subject: [scikit-image] Community guidelines
In-Reply-To: <1508991696.2533515.1151368096.2D42891C@webmail.messagingengine.com>
References: <1508869973.2082990.1149621008.4442203C@webmail.messagingengine.com>
 <a8228e3c-e463-4b1f-aaaa-4e04c0ecbc7b@Spark>
 <1508991696.2533515.1151368096.2D42891C@webmail.messagingengine.com>
Message-ID: <CF198388-26DE-4E82-8A9E-D8CC38ECFDEC@gmail.com>

I agree with Juan.  Also, I had not heard of neurotype, great vocabulary word for the day.


Regards,

Steve


> On Oct 25, 2017, at 11:21 PM, Stefan van der Walt <stefanv at berkeley.edu> wrote:
> 
> Thanks for letting me know, Juan.
> 
> I'd also like to hear from the rest of the community---what are your thoughts?
> 
> St?fan
> 
> On Wed, Oct 25, 2017, at 01:58, Juan Nunez-Iglesias wrote:
>> +1 from me. I specifically like having external people to report incidents to. 
>> 
>> Juan.
>> 
>> On 25 Oct 2017, 5:33 AM +1100, Stefan van der Walt <stefanv at berkeley.edu>, wrote:
>> 
>>> Hi, everyone
>>> 
>>> SciPy just merged their Code of Conduct documents after a long
>>> discussion [0]:
>>> 
>>> https://github.com/scipy/scipy/blob/master/doc/source/dev/conduct/code_of_conduct.rst
>>> https://github.com/scipy/scipy/blob/master/doc/source/dev/conduct/report_handling_manual.rst
>>> 
>>> I have been hesitant to include anything similar for scikit-image before
>>> (other than http://scikit-image.org/community_guidelines.html ), because
>>> I did not feel comfortable with the aloof policing tone typically
>>> employed in similar documents elsewhere.
>>> 
>>> But, I think the SciPy documents make an important statement about our
>>> vision for an inclusive community, and does so in a friendly but serious
>>> way.
>>> 
>>> How would you feel about adopting these documents for scikit-image?
>>> 
>>> Best regards
>>> St?fan
>>> 
>>> [0]: https://github.com/scipy/scipy/pull/7963
>>> _______________________________________________
>>> 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 <mailto:scikit-image at python.org>
>> https://mail.python.org/mailman/listinfo/scikit-image <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/20171026/e1f8baca/attachment.html>

From sccolbert at gmail.com  Thu Oct 26 10:54:54 2017
From: sccolbert at gmail.com (Chris Colbert)
Date: Thu, 26 Oct 2017 09:54:54 -0500
Subject: [scikit-image] Community guidelines
In-Reply-To: <CF198388-26DE-4E82-8A9E-D8CC38ECFDEC@gmail.com>
References: <1508869973.2082990.1149621008.4442203C@webmail.messagingengine.com>
 <a8228e3c-e463-4b1f-aaaa-4e04c0ecbc7b@Spark>
 <1508991696.2533515.1151368096.2D42891C@webmail.messagingengine.com>
 <CF198388-26DE-4E82-8A9E-D8CC38ECFDEC@gmail.com>
Message-ID: <CAPc_zRVAOdvEtZpXGoabvoDWfCYVNCk_uF+CUOum6dLNgHZaXQ@mail.gmail.com>

That's one of the best codes of conduct I've seen. +1 from me.

On Thu, Oct 26, 2017 at 4:58 AM, Steven Silvester <
steven.silvester at gmail.com> wrote:

> I agree with Juan.  Also, I had not heard of neurotype, great vocabulary
> word for the day.
>
>
> Regards,
>
> Steve
>
>
> On Oct 25, 2017, at 11:21 PM, Stefan van der Walt <stefanv at berkeley.edu>
> wrote:
>
> Thanks for letting me know, Juan.
>
> I'd also like to hear from the rest of the community---what are your
> thoughts?
>
> St?fan
>
> On Wed, Oct 25, 2017, at 01:58, Juan Nunez-Iglesias wrote:
>
> +1 from me. I specifically like having external people to report incidents
> to.
>
> Juan.
>
> On 25 Oct 2017, 5:33 AM +1100, Stefan van der Walt <stefanv at berkeley.edu>,
> wrote:
>
> Hi, everyone
>
> SciPy just merged their Code of Conduct documents after a long
> discussion [0]:
>
> https://github.com/scipy/scipy/blob/master/doc/source/
> dev/conduct/code_of_conduct.rst
> https://github.com/scipy/scipy/blob/master/doc/source/
> dev/conduct/report_handling_manual.rst
>
> I have been hesitant to include anything similar for scikit-image before
> (other than http://scikit-image.org/community_guidelines.html ), because
> I did not feel comfortable with the aloof policing tone typically
> employed in similar documents elsewhere.
>
> But, I think the SciPy documents make an important statement about our
> vision for an inclusive community, and does so in a friendly but serious
> way.
>
> How would you feel about adopting these documents for scikit-image?
>
> Best regards
> St?fan
>
> [0]: https://github.com/scipy/scipy/pull/7963
> _______________________________________________
> 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
>
>
> _______________________________________________
> 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/20171026/3ee27df5/attachment-0001.html>

From egor.v.panfilov at gmail.com  Thu Oct 26 11:17:34 2017
From: egor.v.panfilov at gmail.com (Egor Panfilov)
Date: Thu, 26 Oct 2017 18:17:34 +0300
Subject: [scikit-image] Community guidelines
In-Reply-To: <CAPc_zRVAOdvEtZpXGoabvoDWfCYVNCk_uF+CUOum6dLNgHZaXQ@mail.gmail.com>
References: <1508869973.2082990.1149621008.4442203C@webmail.messagingengine.com>
 <a8228e3c-e463-4b1f-aaaa-4e04c0ecbc7b@Spark>
 <1508991696.2533515.1151368096.2D42891C@webmail.messagingengine.com>
 <CF198388-26DE-4E82-8A9E-D8CC38ECFDEC@gmail.com>
 <CAPc_zRVAOdvEtZpXGoabvoDWfCYVNCk_uF+CUOum6dLNgHZaXQ@mail.gmail.com>
Message-ID: <CAPBs059REH-1p=gs=8tc67kZGVzc5jriSi6Ac-5VWa3wMkpz+w@mail.gmail.com>

Looks good to me as well.

Regards,
Egor Panfilov

2017-10-26 17:54 GMT+03:00 Chris Colbert <sccolbert at gmail.com>:

> That's one of the best codes of conduct I've seen. +1 from me.
>
> On Thu, Oct 26, 2017 at 4:58 AM, Steven Silvester <
> steven.silvester at gmail.com> wrote:
>
>> I agree with Juan.  Also, I had not heard of neurotype, great vocabulary
>> word for the day.
>>
>>
>> Regards,
>>
>> Steve
>>
>>
>> On Oct 25, 2017, at 11:21 PM, Stefan van der Walt <stefanv at berkeley.edu>
>> wrote:
>>
>> Thanks for letting me know, Juan.
>>
>> I'd also like to hear from the rest of the community---what are your
>> thoughts?
>>
>> St?fan
>>
>> On Wed, Oct 25, 2017, at 01:58, Juan Nunez-Iglesias wrote:
>>
>> +1 from me. I specifically like having external people to report
>> incidents to.
>>
>> Juan.
>>
>> On 25 Oct 2017, 5:33 AM +1100, Stefan van der Walt <stefanv at berkeley.edu>,
>> wrote:
>>
>> Hi, everyone
>>
>> SciPy just merged their Code of Conduct documents after a long
>> discussion [0]:
>>
>> https://github.com/scipy/scipy/blob/master/doc/source/dev/
>> conduct/code_of_conduct.rst
>> https://github.com/scipy/scipy/blob/master/doc/source/dev/
>> conduct/report_handling_manual.rst
>>
>> I have been hesitant to include anything similar for scikit-image before
>> (other than http://scikit-image.org/community_guidelines.html ), because
>> I did not feel comfortable with the aloof policing tone typically
>> employed in similar documents elsewhere.
>>
>> But, I think the SciPy documents make an important statement about our
>> vision for an inclusive community, and does so in a friendly but serious
>> way.
>>
>> How would you feel about adopting these documents for scikit-image?
>>
>> Best regards
>> St?fan
>>
>> [0]: https://github.com/scipy/scipy/pull/7963
>> _______________________________________________
>> 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
>>
>>
>> _______________________________________________
>> 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
>>
>>
>
> _______________________________________________
> 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/20171026/bcccebe5/attachment.html>

From grlee77 at gmail.com  Thu Oct 26 16:48:36 2017
From: grlee77 at gmail.com (Gregory Lee)
Date: Thu, 26 Oct 2017 16:48:36 -0400
Subject: [scikit-image] Community guidelines
In-Reply-To: <1508869973.2082990.1149621008.4442203C@webmail.messagingengine.com>
References: <1508869973.2082990.1149621008.4442203C@webmail.messagingengine.com>
Message-ID: <CAJR3sXdrAoV=-W_ekN6hv3TaSPtkFy9YDCZVK==UdRB8it67yQ@mail.gmail.com>

+1 from me as well.

On Tue, Oct 24, 2017 at 2:32 PM, Stefan van der Walt <stefanv at berkeley.edu>
wrote:

> Hi, everyone
>
> SciPy just merged their Code of Conduct documents after a long
> discussion [0]:
>
> https://github.com/scipy/scipy/blob/master/doc/source/
> dev/conduct/code_of_conduct.rst
> https://github.com/scipy/scipy/blob/master/doc/source/
> dev/conduct/report_handling_manual.rst
>
> I have been hesitant to include anything similar for scikit-image before
> (other than http://scikit-image.org/community_guidelines.html ), because
> I did not feel comfortable with the aloof policing tone typically
> employed in similar documents elsewhere.
>
> But, I think the SciPy documents make an important statement about our
> vision for an inclusive community, and does so in a friendly but serious
> way.
>
> How would you feel about adopting these documents for scikit-image?
>
> Best regards
> St?fan
>
> [0]: https://github.com/scipy/scipy/pull/7963
> _______________________________________________
> 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/20171026/3d264c51/attachment.html>

From fboulogne at sciunto.org  Fri Oct 27 04:35:45 2017
From: fboulogne at sciunto.org (=?UTF-8?Q?Fran=c3=a7ois_Boulogne?=)
Date: Fri, 27 Oct 2017 10:35:45 +0200
Subject: [scikit-image] Community guidelines
In-Reply-To: <1508869973.2082990.1149621008.4442203C@webmail.messagingengine.com>
References: <1508869973.2082990.1149621008.4442203C@webmail.messagingengine.com>
Message-ID: <86d8191a-f6af-c498-63e1-ab1f747c204e@sciunto.org>

Hi,

The comments are all positive, I'm less optimistic. First, I feel sad to
see that we came to a point that we have to specify such policies in a
FLOSS community. Moreover, beyond the declaration, I always have doubts
regarding the true efficiency of such guidelines in reality... and I'm
embarrassed that some of us have the power to judge, when it's not their
job. This is far from insignificant and could be more harmful than helpful.

my 2 cents.

-- 
Fran?ois Boulogne.
http://www.sciunto.org
GPG: 32D5F22F


From jni.soma at gmail.com  Fri Oct 27 06:09:26 2017
From: jni.soma at gmail.com (Juan Nunez-Iglesias)
Date: Fri, 27 Oct 2017 21:09:26 +1100
Subject: [scikit-image] Community guidelines
In-Reply-To: <86d8191a-f6af-c498-63e1-ab1f747c204e@sciunto.org>
References: <1508869973.2082990.1149621008.4442203C@webmail.messagingengine.com>
 <86d8191a-f6af-c498-63e1-ab1f747c204e@sciunto.org>
Message-ID: <cb001549-6043-424c-802a-0bcde00cb5e6@Spark>


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?

Juan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20171027/cc8f4dde/attachment.html>

From matthew.brett at gmail.com  Fri Oct 27 08:28:58 2017
From: matthew.brett at gmail.com (Matthew Brett)
Date: Fri, 27 Oct 2017 13:28:58 +0100
Subject: [scikit-image] Community guidelines
In-Reply-To: <cb001549-6043-424c-802a-0bcde00cb5e6@Spark>
References: <1508869973.2082990.1149621008.4442203C@webmail.messagingengine.com>
 <86d8191a-f6af-c498-63e1-ab1f747c204e@sciunto.org>
 <cb001549-6043-424c-802a-0bcde00cb5e6@Spark>
Message-ID: <CAH6Pt5r0hHiSO9j3TSXwtkpDCQT33r-a6=UR4xyLaCLQZVgyAw@mail.gmail.com>

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

From stefanv at berkeley.edu  Fri Oct 27 16:42:07 2017
From: stefanv at berkeley.edu (Stefan van der Walt)
Date: Fri, 27 Oct 2017 13:42:07 -0700
Subject: [scikit-image] Community guidelines
In-Reply-To: <CAH6Pt5r0hHiSO9j3TSXwtkpDCQT33r-a6=UR4xyLaCLQZVgyAw@mail.gmail.com>
References: <1508869973.2082990.1149621008.4442203C@webmail.messagingengine.com>
 <86d8191a-f6af-c498-63e1-ab1f747c204e@sciunto.org>
 <cb001549-6043-424c-802a-0bcde00cb5e6@Spark>
 <CAH6Pt5r0hHiSO9j3TSXwtkpDCQT33r-a6=UR4xyLaCLQZVgyAw@mail.gmail.com>
Message-ID: <1509136927.1496359.1153404296.764CDDA0@webmail.messagingengine.com>

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20171027/29c957a5/attachment.html>

From silvertrumpet999 at gmail.com  Fri Oct 27 20:42:18 2017
From: silvertrumpet999 at gmail.com (Josh Warner)
Date: Fri, 27 Oct 2017 17:42:18 -0700
Subject: [scikit-image] Community guidelines
In-Reply-To: <1509136927.1496359.1153404296.764CDDA0@webmail.messagingengine.com>
References: <1508869973.2082990.1149621008.4442203C@webmail.messagingengine.com>
 <86d8191a-f6af-c498-63e1-ab1f747c204e@sciunto.org>
 <cb001549-6043-424c-802a-0bcde00cb5e6@Spark>
 <CAH6Pt5r0hHiSO9j3TSXwtkpDCQT33r-a6=UR4xyLaCLQZVgyAw@mail.gmail.com>
 <1509136927.1496359.1153404296.764CDDA0@webmail.messagingengine.com>
Message-ID: <CADnryEcK=r2KNQPPFbf-gHYpoBOWuWc3pB9jdnkDQ5FY7Jsjwg@mail.gmail.com>

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>

From ralf.gommers at gmail.com  Sat Oct 28 01:06:47 2017
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sat, 28 Oct 2017 18:06:47 +1300
Subject: [scikit-image] Community guidelines
In-Reply-To: <CADnryEcK=r2KNQPPFbf-gHYpoBOWuWc3pB9jdnkDQ5FY7Jsjwg@mail.gmail.com>
References: <1508869973.2082990.1149621008.4442203C@webmail.messagingengine.com>
 <86d8191a-f6af-c498-63e1-ab1f747c204e@sciunto.org>
 <cb001549-6043-424c-802a-0bcde00cb5e6@Spark>
 <CAH6Pt5r0hHiSO9j3TSXwtkpDCQT33r-a6=UR4xyLaCLQZVgyAw@mail.gmail.com>
 <1509136927.1496359.1153404296.764CDDA0@webmail.messagingengine.com>
 <CADnryEcK=r2KNQPPFbf-gHYpoBOWuWc3pB9jdnkDQ5FY7Jsjwg@mail.gmail.com>
Message-ID: <CABL7CQgCryxOTj8MPwCU0jH=YRaZL0-myPrCKzjB0K+2B_4Zdg@mail.gmail.com>

On Sat, Oct 28, 2017 at 1:42 PM, Josh Warner <silvertrumpet999 at gmail.com>
wrote:

> 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.
>

The word "safe" is not present in the SciPy CoC. Your reservations and even
the article you link were brought up several times by Matthew Brett, who
was very thorough in going through that CoC and changing or removing
language that came from this political background you're not supporting. So
I think your concerns are about CoC's in general rather than about the
SciPy CoC or Stefan's concrete proposal.


  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*,
>

Eh, no. The spirit of the document is way more important than the letter.

Ralf

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
>>
>>
>
> _______________________________________________
> 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/20171028/77621b3f/attachment-0001.html>

From matthew.brett at gmail.com  Sat Oct 28 05:51:19 2017
From: matthew.brett at gmail.com (Matthew Brett)
Date: Sat, 28 Oct 2017 10:51:19 +0100
Subject: [scikit-image] Community guidelines
In-Reply-To: <CADnryEcK=r2KNQPPFbf-gHYpoBOWuWc3pB9jdnkDQ5FY7Jsjwg@mail.gmail.com>
References: <1508869973.2082990.1149621008.4442203C@webmail.messagingengine.com>
 <86d8191a-f6af-c498-63e1-ab1f747c204e@sciunto.org>
 <cb001549-6043-424c-802a-0bcde00cb5e6@Spark>
 <CAH6Pt5r0hHiSO9j3TSXwtkpDCQT33r-a6=UR4xyLaCLQZVgyAw@mail.gmail.com>
 <1509136927.1496359.1153404296.764CDDA0@webmail.messagingengine.com>
 <CADnryEcK=r2KNQPPFbf-gHYpoBOWuWc3pB9jdnkDQ5FY7Jsjwg@mail.gmail.com>
Message-ID: <CAH6Pt5pY19N81nMiUgdzVB18coDAjuxsSstbY_GBYt6SRSjAZg@mail.gmail.com>

Hi,

On Sat, Oct 28, 2017 at 1:42 AM, Josh Warner <silvertrumpet999 at gmail.com> wrote:
> 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/.

As Ralf said - we did do some work to try and remove references to
"safe", exactly because it refers to that particular culture, on which
we certainly do not have consensus.  But - if you think we didn't do
that effectively enough, please do feel free to give a PR to the Scipy
code of conduct, or put up a PR for your own version to scikit-image.
In this case, I do think it has a lot to do with wording.

I partly agree with you about letter compared to spirit.  My concern
is about the use of the code of conduct as a means of undermining or
removing people that you don't like.  To avoid that, we have to be
very transparent, and very explicit about what we don't allow, to make
it more difficult for a bad actor to label their target unfairly.  If
you haven't read it, I strongly recommend Ken Westhues' site on
Mobbing in Academia :

http://kwesthues.com/mobbing.htm

It gives many examples where groups of people in a department used
poorly framed subjective rules and not-transparent procedures to bully
and remove colleagues that the group had identified as undesirable.
He also points out that this is pretty common, in academia and in
other organizations.

Cheers,

Matthew

From stefanv at berkeley.edu  Sat Oct 28 16:51:20 2017
From: stefanv at berkeley.edu (Stefan van der Walt)
Date: Sat, 28 Oct 2017 13:51:20 -0700
Subject: [scikit-image] Community guidelines
In-Reply-To: <CAH6Pt5pY19N81nMiUgdzVB18coDAjuxsSstbY_GBYt6SRSjAZg@mail.gmail.com>
References: <1508869973.2082990.1149621008.4442203C@webmail.messagingengine.com>
 <86d8191a-f6af-c498-63e1-ab1f747c204e@sciunto.org>
 <cb001549-6043-424c-802a-0bcde00cb5e6@Spark>
 <CAH6Pt5r0hHiSO9j3TSXwtkpDCQT33r-a6=UR4xyLaCLQZVgyAw@mail.gmail.com>
 <1509136927.1496359.1153404296.764CDDA0@webmail.messagingengine.com>
 <CADnryEcK=r2KNQPPFbf-gHYpoBOWuWc3pB9jdnkDQ5FY7Jsjwg@mail.gmail.com>
 <CAH6Pt5pY19N81nMiUgdzVB18coDAjuxsSstbY_GBYt6SRSjAZg@mail.gmail.com>
Message-ID: <1509223880.3241639.1154134896.6BCF71DD@webmail.messagingengine.com>

On Sat, Oct 28, 2017, at 02:51, Matthew Brett wrote:
> As Ralf said - we did do some work to try and remove references to
> "safe", exactly because it refers to that particular culture, on which
> we certainly do not have consensus.  But - if you think we didn't do
> that effectively enough, please do feel free to give a PR to the Scipy
> code of conduct, or put up a PR for your own version to scikit-image.
> In this case, I do think it has a lot to do with wording.

I think it would be worth raising specific phrasing issues here on the
mailing list, so that we can examine them individually.

I started this conversation because I think the SciPy CoC is different
from many others I've seen, in that it does not make many of the choices
in wording others do and tries to be cognizant of the wide array of
political opinions and cultural norms present.

As I stated in a previous email, not writing rules down does not mean
they do not exist implicitly.

Best regards
St?fan