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

[Charles R Harris]

On Sat, Aug 26, 2017 at 7:32 PM, Nathaniel Smith <njs at pobox.com> wrote:

> On Sat, Aug 26, 2017 at 6:14 PM, Ralf Gommers <ralf.gommers at gmail.com>
> wrote:
> >
> >
> > On Sun, Aug 27, 2017 at 12:13 PM, Charles R Harris
> > <charlesr.harris at gmail.com> wrote:
> >>
> >>
> >>
> >> On Thu, Aug 24, 2017 at 4:11 AM, Ralf Gommers <ralf.gommers at gmail.com>
> >> wrote:
> >>>
> >>>
> >>>
> >>> On Sun, Aug 20, 2017 at 12:53 PM, Ralf Gommers <ralf.gommers at gmail.com
> >
> >>> wrote:
> >>>>
> >>>> Hi all,
> >>>>
> >>>> I propose that we as SciPy developers and community adopt a Code of
> >>>> Conduct.
> >>>>
> >>>> As you probably know, Code of Conduct (CoC) documents are becoming
> more
> >>>> common every year for open source projects, and there are a number of
> good
> >>>> reasons to adopt a CoC:
> >>>> 1. It gives us the opportunity to explicitly express the values and
> >>>> behaviors we'd like to see in our community.
> >>>> 2. It is designed to make everyone feel welcome (and while I think
> we're
> >>>> a welcoming community anyway, not having a CoC may look explicitly
> >>>> unwelcoming to some potential contributors nowadays).
> >>>> 3. It gives us a tool to address a set of problems if and when they
> >>>> occur, as well as a way for anyone to report issues or behavior that
> is
> >>>> unacceptable to them (much better than having those people
> potentially leave
> >>>> the community).
> >>>> 4. SciPy is not yet a fiscally sponsored project of NumFOCUS, however
> I
> >>>> think we'd like to be in the near future.  NumFOCUS has started to
> require
> >>>> having a CoC as a prerequisite for new projects joining it.  The PSF
> has the
> >>>> same requirement for any sponsorship for events/projects that it
> gives.
> >>>>
> >>>> Also note that GitHub has starting checking the presence of a CoC
> fairly
> >>>> prominently (https://github.com/scipy/scipy/community), and has also
> >>>> produced a guide with things to think about when formulating a CoC:
> >>>> https://opensource.guide/code-of-conduct/. I recommend reading that
> guide
> >>>> (as well as others guides on that site), it's really good.
> >>>>
> >>>> To get to a CoC document, a good approach is to borrow text from a CoC
> >>>> that has been in use for a while and has proven to be valuable, and
> then
> >>>> modify where needed (similar to a software license - don't invent
> your own).
> >>>> I considered three existing CoC's:
> >>>> - The Contributor Covenant
> >>>> (http://contributor-covenant.org/version/1/2/0/): simple, concise,
> the most
> >>>> widely used one. The NumFOCUS recommended one is based on it as well
> >>>> (https://www.numfocus.org/about/code-of-conduct/).
> >>>> - The Python Community Code of Conduct
> >>>> (https://www.python.org/psf/codeofconduct/): also simple, addresses
> mostly
> >>>> the spirit in which the Python community is operating / should
> operate.
> >>>> - The Jupyter Code of Conduct
> >>>> (https://github.com/jupyter/governance/tree/master/conduct): much
> more
> >>>> detailed, in part derived from the Speak up! and Django ones, more
> >>>> appropriate for large communities.
> >>>>
> >>
> >> The contributor covenant looks excellent, short, well structured, and
> easy
> >> to understand. I'd suggest adding just a bit for clarification, for
> >> instance, what venues (mailing lists, github) are considered in the
> SciPy
> >> domain, and a bit on whom to contact in case of problems.
> >
> >
> > Thanks for the feedback Chuck. Pauli said on GitHub he preferred
> something
> > shorter and less flowery as well, so that's two votes for the contributor
> > covenant or something more in that direction.
>
> It looks like the link above goes to the 1.2 version of the
> Contributor Covenant, while the latest version is 1.4:
>
>     https://www.contributor-covenant.org/version/1/4/
>
> The 1.4 version has a little more detail on venues and a slot to put
> in a contact address.
>
>
The extra sections are good but I think the long enumerations dilute the
message. All means all is a stronger statement than a list of every
conceivable attribute. I think the 1.2 version is better in that regard.

I do think there needs to be at least somewhat more detail on how
> reports will be handled -- the last thing you need while trying to
> handle a painful and delicate issue is to also be trying to figure
> out, like, which mailing list you can use to talk about it or whether
> you need to be setting up a new one. At least something like "we'll
> have a small committee, they'll have a private mailing list, archives
> will be available to the committee members but otherwise confidential,
> reports will be acknowledged quickly, if a complaint is about someone
> on the committee then they'll recuse themselves", that kind of stuff.
>
>
At the least we should be in a position to handle a complaint if one shows
up. Looks like some of the organizations have a separate enforcement
manual, which I think is a good idea. Most SciPy interactions are in public
venues which should help.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20170826/c8c82a6f/attachment-0001.html>