establishing a Code of Conduct for SciPy
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. I think the Python Community CoC isn't a good basis, it's more a statement of intent for a wider community while it's missing too many elements that a project CoC should have. That leaves the choice between the short and simple Contributor Covenant, and the more extensive Jupyter one. Personally I like the tone of the Jupyter one *much* more, so I have started from that one and made the following modifications to make it fit SciPy better: 1. Removed the part about reporting during events (we don't organize those) and removed the language about events from the faq. 2. Changes to reporting options: removed the form (email should be enough), and added reporting to NumFOCUS as a second option. 3. Changes to enforcement manual: reply within 72 hours rather than 24 hours (we don't have paid work on SciPy, so 24 hours is not very realistic). Changed the committee from 5 to 3 members (5 is a lot, and we're significantly smaller than Jupyter/Django). Here is a WIP PR with the CoC content: https://github.com/scipy/scipy/pull/7764. I suggest to bring up any larger questions/issues here, and detailed textual comments on the PR. Once the content is agreed upon I will change it to reST and integrate it with the rest of the docs. Thoughts? Volunteers for the committee? Cheers, Ralf
On Sun, Aug 20, 2017 at 12:53 PM, Ralf Gommers <ralf.gommers@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.
I think the Python Community CoC isn't a good basis, it's more a statement of intent for a wider community while it's missing too many elements that a project CoC should have. That leaves the choice between the short and simple Contributor Covenant, and the more extensive Jupyter one. Personally I like the tone of the Jupyter one *much* more,
It was pointed out to me that the process/discussion of introducing a CoC for Jupyter happened in a very sub-optimal way, and not everyone who was involved was happy with the end result. Clearly we want to avoid repeating any mistakes that were made there, so here's a plan: a) Have multiple ways to give feedback (not everyone may be comfortable doing so on a public list), and take that seriously. Feedback in private is very welcome. Also, we'll hold an open conference call (after step (b) is done, I'll send out a time/date later). b) Iterate on the content of the PR a bit to address item 4 below. Matthew has offered to take the lead on this. My high level objectives were: 1. We need to have a CoC 2. It has to have a friendly tone 3. It has to have an enforcement mechanism A (imho valid) criticism of the Jupyter CoC is that it's too vague on what is/isn't allowed and what potential consequences are of doing something that isn't allowed. It's clearly not possible to cover every scenario, however things can be illustrated by example. E.g. just being a little unfriendly will not get you banned from the mailing list (but maybe will result in a private email asking to keep it friendly), while threatening with physical violence will. And robust discussion is still very welcome. So objective to add: 4. Be clear on what is and isn't okay, and how that will be handled. So update to follow. Hopefully we end up with everyone being happy with both the content of the CoC and the way we arrived at it. Cheers, Ralf
so I have started from that one and made the following modifications to make it fit SciPy better:
1. Removed the part about reporting during events (we don't organize those) and removed the language about events from the faq. 2. Changes to reporting options: removed the form (email should be enough), and added reporting to NumFOCUS as a second option. 3. Changes to enforcement manual: reply within 72 hours rather than 24 hours (we don't have paid work on SciPy, so 24 hours is not very realistic). Changed the committee from 5 to 3 members (5 is a lot, and we're significantly smaller than Jupyter/Django).
Here is a WIP PR with the CoC content: https://github.com/scipy/ scipy/pull/7764. I suggest to bring up any larger questions/issues here, and detailed textual comments on the PR. Once the content is agreed upon I will change it to reST and integrate it with the rest of the docs.
Thoughts? Volunteers for the committee?
Cheers, Ralf
On Thu, Aug 24, 2017 at 4:11 AM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Sun, Aug 20, 2017 at 12:53 PM, Ralf Gommers <ralf.gommers@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.o rg/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/co deofconduct/): also simple, addresses mostly the spirit in which the Python community is operating / should operate. - The Jupyter Code of Conduct (https://github.com/jupyter/go vernance/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. Chuck
On Sun, Aug 27, 2017 at 12:13 PM, Charles R Harris < charlesr.harris@gmail.com> wrote:
On Thu, Aug 24, 2017 at 4:11 AM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Sun, Aug 20, 2017 at 12:53 PM, Ralf Gommers <ralf.gommers@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.o rg/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/co deofconduct/): also simple, addresses mostly the spirit in which the Python community is operating / should operate. - The Jupyter Code of Conduct (https://github.com/jupyter/go vernance/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. Cheers, Ralf
On Sat, Aug 26, 2017 at 6:14 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Sun, Aug 27, 2017 at 12:13 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Thu, Aug 24, 2017 at 4:11 AM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Sun, Aug 20, 2017 at 12:53 PM, Ralf Gommers <ralf.gommers@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. 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. -n -- Nathaniel J. Smith -- https://vorpus.org
On Sat, Aug 26, 2017 at 7:32 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Sat, Aug 26, 2017 at 6:14 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Sun, Aug 27, 2017 at 12:13 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Thu, Aug 24, 2017 at 4:11 AM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Sun, Aug 20, 2017 at 12:53 PM, Ralf Gommers <ralf.gommers@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
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
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
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,
more potentially leave then 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
On Sat, Aug 26, 2017 at 7:57 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Sat, Aug 26, 2017 at 7:32 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Sat, Aug 26, 2017 at 6:14 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
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.
Folks who look like you or me aren't really the intended audience for this – we already know we're included :-). The important thing is how the message comes across to those who might otherwise feel excluded. So I think this is a place where we should defer to the experts. -n -- Nathaniel J. Smith -- https://vorpus.org
Regarding long enumerations, I would suggest that the added bullet points are examples of *positive* behavior. There are actually fewer examples of *negative *behavior in 1.4. I think this improves the tone. I prefer the addition of the positive examples in 1.4, the space for contacting the project team, the organization/headings of each section, and the overall wording of 1.4. It seems more comprehensive and professional. On Tue, Aug 29, 2017 at 10:32 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Sat, Aug 26, 2017 at 7:57 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Sat, Aug 26, 2017 at 7:32 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Sat, Aug 26, 2017 at 6:14 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
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.
Folks who look like you or me aren't really the intended audience for this – we already know we're included :-). The important thing is how the message comes across to those who might otherwise feel excluded. So I think this is a place where we should defer to the experts.
-n
-- Nathaniel J. Smith -- https://vorpus.org _______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev
-- Matt Haberland Assistant Adjunct Professor in the Program in Computing Department of Mathematics 7620E Math Sciences Building, UCLA
On Sat, Sep 9, 2017 at 6:03 AM, Matt Haberland <haberland@ucla.edu> wrote:
Regarding long enumerations, I would suggest that the added bullet points are examples of *positive* behavior. There are actually fewer examples of *negative *behavior in 1.4. I think this improves the tone.
I prefer the addition of the positive examples in 1.4, the space for contacting the project team, the organization/headings of each section, and the overall wording of 1.4. It seems more comprehensive and professional.
I agree. That new version addresses my concern about the harsh tone of version 1.2. Overall there seems to be a preference for the Contributor Covenant or at least something of that level of conciseness, rather than the Jupyter/Django style CoC. So let's go in that direction. Ralf
On Tue, Aug 29, 2017 at 10:32 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Sat, Aug 26, 2017 at 7:57 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Sat, Aug 26, 2017 at 7:32 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Sat, Aug 26, 2017 at 6:14 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
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.
Folks who look like you or me aren't really the intended audience for this – we already know we're included :-). The important thing is how the message comes across to those who might otherwise feel excluded. So I think this is a place where we should defer to the experts.
-n
-- Nathaniel J. Smith -- https://vorpus.org _______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev
-- Matt Haberland Assistant Adjunct Professor in the Program in Computing Department of Mathematics 7620E Math Sciences Building, UCLA
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev
la, 2017-09-09 kello 15:24 +1200, Ralf Gommers kirjoitti:
I agree. That new version addresses my concern about the harsh tone of version 1.2.
Overall there seems to be a preference for the Contributor Covenant or at least something of that level of conciseness, rather than the Jupyter/Django style CoC. So let's go in that direction.
The text of the current version of the Contributor Covenant seems easy to understand and fairly reasonable to me. The scope where it applies is clearly defined, and essentially codifies not accepting wildly unprofessional behavior on scipy issue trackers etc. It is also adopted by a number of other projects, so I think it is a better starting point. Pauli
On Mon, Sep 11, 2017 at 2:06 AM, Pauli Virtanen <pav@iki.fi> wrote:
la, 2017-09-09 kello 15:24 +1200, Ralf Gommers kirjoitti:
I agree. That new version addresses my concern about the harsh tone of version 1.2.
Overall there seems to be a preference for the Contributor Covenant or at least something of that level of conciseness, rather than the Jupyter/Django style CoC. So let's go in that direction.
The text of the current version of the Contributor Covenant seems easy to understand and fairly reasonable to me. The scope where it applies is clearly defined, and essentially codifies not accepting wildly unprofessional behavior on scipy issue trackers etc. It is also adopted by a number of other projects, so I think it is a better starting point.
Agreed. There's also the Apache one ( https://www.apache.org/foundation/policies/conduct.html, thanks to Stefan for the suggestion), which is also clear and concise, and has a much friendlier tone than the Contributor Covenant. Ralf
Hi, On Mon, Sep 11, 2017 at 9:44 AM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Mon, Sep 11, 2017 at 2:06 AM, Pauli Virtanen <pav@iki.fi> wrote:
la, 2017-09-09 kello 15:24 +1200, Ralf Gommers kirjoitti:
I agree. That new version addresses my concern about the harsh tone of version 1.2.
Overall there seems to be a preference for the Contributor Covenant or at least something of that level of conciseness, rather than the Jupyter/Django style CoC. So let's go in that direction.
The text of the current version of the Contributor Covenant seems easy to understand and fairly reasonable to me. The scope where it applies is clearly defined, and essentially codifies not accepting wildly unprofessional behavior on scipy issue trackers etc. It is also adopted by a number of other projects, so I think it is a better starting point.
Agreed. There's also the Apache one (https://www.apache.org/foundation/policies/conduct.html, thanks to Stefan for the suggestion), which is also clear and concise, and has a much friendlier tone than the Contributor Covenant.
I greatly dislike the Contributor Covenant - I find it to be a unpleasant, intimidating document. Just for example, if you run it through https://readable.io/text/, it gets an E for Readability (on an A-E scale), Moderately Formal, and a 100% score for Male on a Male / Female detection algorithm. I am not sure I really like the Apache code of conduct, but I think it's much better - more positive, direct and friendly in tone. I could certainly live with it. Just for comparison, C for readability, Slightly Formal, about 78% Male. Cheers, Matthew
Ralf Gommers kirjoitti 11.09.2017 klo 10:44: [clip]
There's also the Apache one ( https://www.apache.org/foundation/policies/conduct.html, thanks to Stefan for the suggestion), which is also clear and concise, and has a much friendlier tone than the Contributor Covenant.
If we look at the content, there seem to be differences between (A)pache to the (C)ontributor Covenant: - (A) talks about good behavior in detail, including how to write good emails, communication expected when resigning from projects, etc. - (A) suggests to try to deal with the issues by reminding about the CoC. - (C) promises maintainers will consider and take fair action on complaints if necessary. (A) does not promise someone will do something. - (C) gives examples of possible actions taken, (A) not. So it seems that the promises are weaker, and I think the content of the text is here important. *** It seems to me that these documents generally try to do both (1) outline community guidelines for "good professional behavior", and (2) lay out anti-harassment/discrimination/trolling/etc rules. Here, it appears to me (A) is more about (1), and (C) is mainly about (2). The tone probably different because of this. I think Scipy has benefited from being a fairly technical project where contributors often have professional and academic background, with existing norms about collegial behavior and communication, and I like to think that this has been reflected in the discussions. It can of course be useful to think about writing such things down explicitly to produce a document explaining (1), and I think the Apache one gives good hints for keeping things productive. But it is less clear to me this is something for which formal moderator action would be necessary. However, if I understand correctly, the reason why people want these things is more about (2). Indeed, this is standard stuff in the workplace and in moderation of internet forums (usually in "Rules" in the latter). It seems a good idea to structure this part so that it does not fail if someone acts in bad faith, and so that the moderation plan is reasonable to the reader and possible to implement. Pauli
On Mon, Sep 11, 2017, at 14:08, Pauli Virtanen wrote:
It can of course be useful to think about writing such things down explicitly to produce a document explaining (1), and I think the Apache one gives good hints for keeping things productive. But it is less clear to me this is something for which formal moderator action would be necessary.
However, if I understand correctly, the reason why people want these things is more about (2). Indeed, this is standard stuff in the workplace and in moderation of internet forums (usually in "Rules" in the latter). It seems a good idea to structure this part so that it does not fail if someone acts in bad faith, and so that the moderation plan is reasonable to the reader and possible to implement.
I feel it is important to mix in a bit of (1) with (2), the reason being that almost every person reading the CoC will not ever act in bad faith. You'd think that those people could simply ignore language related to enforcement, but in previous discussions (e.g., around the Jupyter CoC) that turned out not to be the case: it is all too easy to frighten people into not speaking up. So, I'd recommend focusing on a description of the kind of community we want, instead of what we're trying to avoid; and postponing the enforcement language until later in the document, making it clear that enforcement only comes through (somewhat wide) deliberation of trusted community members (and, preferably, also after engagement with the offending party). This way, we can hopefully instill trust in our CoC as a process, rather than a set of rules. Best regards Stéfan
On Tue, Sep 12, 2017 at 12:08 PM, Stefan van der Walt <stefanv@berkeley.edu> wrote:
On Mon, Sep 11, 2017, at 14:08, Pauli Virtanen wrote:
It can of course be useful to think about writing such things down explicitly to produce a document explaining (1), and I think the Apache one gives good hints for keeping things productive. But it is less clear to me this is something for which formal moderator action would be necessary.
However, if I understand correctly, the reason why people want these things is more about (2). Indeed, this is standard stuff in the workplace and in moderation of internet forums (usually in "Rules" in the latter).
Agreed that many people want it for (2). There's an important difference though. Forum rules and workplace policies are usually not very visible, while with a CoC for an open source project one wants it to be quite visible. Therefore the importance of it having a positive tone and statements about what we value is a lot more important than for something like a workplace policy. It seems a good idea to structure this part so that it
does not fail if someone acts in bad faith, and so that the moderation plan is reasonable to the reader and possible to implement.
I feel it is important to mix in a bit of (1) with (2), the reason being that almost every person reading the CoC will not ever act in bad faith. You'd think that those people could simply ignore language related to enforcement, but in previous discussions (e.g., around the Jupyter CoC) that turned out not to be the case: it is all too easy to frighten people into not speaking up.
So, I'd recommend focusing on a description of the kind of community we want, instead of what we're trying to avoid; and postponing the enforcement language until later in the document, making it clear that enforcement only comes through (somewhat wide) deliberation of trusted community members (and, preferably, also after engagement with the offending party).
This way, we can hopefully instill trust in our CoC as a process, rather than a set of rules.
That sounds quite good to me. The process at a high level (for all but the most severe cases) should be something like: 1. complaint 2. reasonable discussion/feedback 3. mediation (if feedback didn't help) 4. enforcement via transparent decision by CoC committee (if mediation failed) And not what some people may be afraid of, and sometimes actually happens in practice: 1. complaint 2. enforcement For a new CoC draft, taking most of the Apache doc and tacking the more rules/enforcement oriented content of the Contributor Covenant onto the end seems like a good starting point. Ralf
Hi, On Wed, Sep 13, 2017 at 11:39 AM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Tue, Sep 12, 2017 at 12:08 PM, Stefan van der Walt <stefanv@berkeley.edu> wrote:
On Mon, Sep 11, 2017, at 14:08, Pauli Virtanen wrote:
It can of course be useful to think about writing such things down explicitly to produce a document explaining (1), and I think the Apache one gives good hints for keeping things productive. But it is less clear to me this is something for which formal moderator action would be necessary.
However, if I understand correctly, the reason why people want these things is more about (2). Indeed, this is standard stuff in the workplace and in moderation of internet forums (usually in "Rules" in the latter).
Agreed that many people want it for (2). There's an important difference though. Forum rules and workplace policies are usually not very visible, while with a CoC for an open source project one wants it to be quite visible. Therefore the importance of it having a positive tone and statements about what we value is a lot more important than for something like a workplace policy.
Yes - I agree strongly. I think this does do dual service as a statement of values as well as well as a threat of enforcement.
It seems a good idea to structure this part so that it
does not fail if someone acts in bad faith, and so that the moderation plan is reasonable to the reader and possible to implement.
I feel it is important to mix in a bit of (1) with (2), the reason being that almost every person reading the CoC will not ever act in bad faith. You'd think that those people could simply ignore language related to enforcement, but in previous discussions (e.g., around the Jupyter CoC) that turned out not to be the case: it is all too easy to frighten people into not speaking up.
So, I'd recommend focusing on a description of the kind of community we want, instead of what we're trying to avoid; and postponing the enforcement language until later in the document, making it clear that enforcement only comes through (somewhat wide) deliberation of trusted community members (and, preferably, also after engagement with the offending party).
This way, we can hopefully instill trust in our CoC as a process, rather than a set of rules.
That sounds quite good to me. The process at a high level (for all but the most severe cases) should be something like:
1. complaint 2. reasonable discussion/feedback 3. mediation (if feedback didn't help) 4. enforcement via transparent decision by CoC committee (if mediation failed)
Yes, I like that list a lot. Although, I was proposing in the Jupyter discussion, that informal mediation be triggered really early, to help people get over the feeling of being isolated, that can easily arise in on-line communication - see : https://github.com/jupyter/governance/pull/23#issuecomment-269352416 . This was partly based on my reading of [1] (see quote), which suggested that one reason that women can find online forums intimidating is the lack of a mentor to guide them through the thickets of unfamiliar jargon, habits, and cliques. And partly because, having read that, I realized I felt the same way.
And not what some people may be afraid of, and sometimes actually happens in practice: 1. complaint 2. enforcement
For a new CoC draft, taking most of the Apache doc and tacking the more rules/enforcement oriented content of the Contributor Covenant onto the end seems like a good starting point.
Yes, I agree with that too ... :) Cheers, Matthew [1] https://suegardner.org/2011/02/19/nine-reasons-why-women-dont-edit-wikipedia... """ The few times I’ve touched wikipedia, I’ve been struck by how isolating it can feel. It’s a very fend for yourself kind of place for me. Anywhere else online, my first impulse is to put out feelers. I make friends, ask for links to FAQs and guides, and inevitably someone takes me under their wing and shows me the ropes of whatever niche culture I’m obsessed with that month. """
On Thu, Sep 14, 2017 at 12:12 AM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Wed, Sep 13, 2017 at 11:39 AM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Tue, Sep 12, 2017 at 12:08 PM, Stefan van der Walt <
stefanv@berkeley.edu>
wrote:
On Mon, Sep 11, 2017, at 14:08, Pauli Virtanen wrote:
It can of course be useful to think about writing such things down explicitly to produce a document explaining (1), and I think the
Apache
one gives good hints for keeping things productive. But it is less clear to me this is something for which formal moderator action would be necessary.
However, if I understand correctly, the reason why people want these things is more about (2). Indeed, this is standard stuff in the workplace and in moderation of internet forums (usually in "Rules" in the latter).
Agreed that many people want it for (2). There's an important difference though. Forum rules and workplace policies are usually not very visible, while with a CoC for an open source project one wants it to be quite visible. Therefore the importance of it having a positive tone and statements about what we value is a lot more important than for something like a workplace policy.
Yes - I agree strongly. I think this does do dual service as a statement of values as well as well as a threat of enforcement.
It seems a good idea to structure this part so that it
does not fail if someone acts in bad faith, and so that the moderation plan is reasonable to the reader and possible to implement.
I feel it is important to mix in a bit of (1) with (2), the reason being that almost every person reading the CoC will not ever act in bad faith. You'd think that those people could simply ignore language related to enforcement, but in previous discussions (e.g., around the Jupyter CoC) that turned out not to be the case: it is all too easy to frighten people into not speaking up.
So, I'd recommend focusing on a description of the kind of community we want, instead of what we're trying to avoid; and postponing the enforcement language until later in the document, making it clear that enforcement only comes through (somewhat wide) deliberation of trusted community members (and, preferably, also after engagement with the offending party).
This way, we can hopefully instill trust in our CoC as a process, rather than a set of rules.
That sounds quite good to me. The process at a high level (for all but the most severe cases) should be something like:
1. complaint 2. reasonable discussion/feedback 3. mediation (if feedback didn't help) 4. enforcement via transparent decision by CoC committee (if mediation failed)
Yes, I like that list a lot. Although, I was proposing in the Jupyter discussion, that informal mediation be triggered really early, to help people get over the feeling of being isolated, that can easily arise in on-line communication - see : https://github.com/jupyter/governance/pull/23#issuecomment-269352416 . This was partly based on my reading of [1] (see quote), which suggested that one reason that women can find online forums intimidating is the lack of a mentor to guide them through the thickets of unfamiliar jargon, habits, and cliques. And partly because, having read that, I realized I felt the same way.
And not what some people may be afraid of, and sometimes actually happens in practice: 1. complaint 2. enforcement
For a new CoC draft, taking most of the Apache doc and tacking the more rules/enforcement oriented content of the Contributor Covenant onto the end seems like a good starting point.
Yes, I agree with that too ... :)
Hi all, here is a new version of the CoC taking this approach: https://github.com/scipy/scipy/pull/7963 Please have a look and comment. Higher level discussion better on this list, detailed textual comments on the PR itself. Cheers, Ralf
Cheers,
Matthew
[1] https://suegardner.org/2011/02/19/nine-reasons-why-women- dont-edit-wikipedia-in-their-own-words
""" The few times I’ve touched wikipedia, I’ve been struck by how isolating it can feel. It’s a very fend for yourself kind of place for me. Anywhere else online, my first impulse is to put out feelers. I make friends, ask for links to FAQs and guides, and inevitably someone takes me under their wing and shows me the ropes of whatever niche culture I’m obsessed with that month. """ _______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev
I am more a lurker than a contributor, but I would like to suggest caution with respect to item #5 in the proposed CoC. +5. Be concise. Keep in mind that what you write once will be read by hundreds + of persons. Writing a short email means people can understand the + conversation as efficiently as possible. Short emails should always strive + to be empathetic, welcoming, friendly and patient. When a long explanation + is necessary, consider adding a summary. I suggest that you should stress more that people should strive for clarity and completeness, and then say that brief and comprehensive is the desired goal. I think you're leaning on short too hard, and that will encourage incomplete more than real concision. There are my reasons: 1) one person's concise could well be another's incomplete. 2) There are many, many terms that have more than one use, or that have different meanings in different contexts, or may have connotations; sometimes being concise leads to use of seemingly unambiguous terms that do turn out to be ambiguous. For those who would reply that the definition of 'concise' implies completeness, as in the definition given: giving a lot of information clearly and in a few words; brief but comprehensive. In popular speech, and to those who may have been over-exposed to some kinds of management, concise is more likely to be interpreted as 'abbreviated', which highlights my second point above. I myself often interpret 'concise' to mean 'short' and often 'abbreviated', because that is what I have (alas) become accustomed to in my work environment. Language evolved to have a lot of redundancy built into it for a reason. Stripping it of too much is as bad as including too much. I hope I was sufficiently concise. ;-) On Mon, Oct 2, 2017 at 5:11 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Thu, Sep 14, 2017 at 12:12 AM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Wed, Sep 13, 2017 at 11:39 AM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Tue, Sep 12, 2017 at 12:08 PM, Stefan van der Walt <stefanv@berkeley.edu> wrote:
On Mon, Sep 11, 2017, at 14:08, Pauli Virtanen wrote:
It can of course be useful to think about writing such things down explicitly to produce a document explaining (1), and I think the Apache one gives good hints for keeping things productive. But it is less clear to me this is something for which formal moderator action would be necessary.
However, if I understand correctly, the reason why people want these things is more about (2). Indeed, this is standard stuff in the workplace and in moderation of internet forums (usually in "Rules" in the latter).
Agreed that many people want it for (2). There's an important difference though. Forum rules and workplace policies are usually not very visible, while with a CoC for an open source project one wants it to be quite visible. Therefore the importance of it having a positive tone and statements about what we value is a lot more important than for something like a workplace policy.
Yes - I agree strongly. I think this does do dual service as a statement of values as well as well as a threat of enforcement.
It seems a good idea to structure this part so that it
does not fail if someone acts in bad faith, and so that the moderation plan is reasonable to the reader and possible to implement.
I feel it is important to mix in a bit of (1) with (2), the reason being that almost every person reading the CoC will not ever act in bad faith. You'd think that those people could simply ignore language related to enforcement, but in previous discussions (e.g., around the Jupyter CoC) that turned out not to be the case: it is all too easy to frighten people into not speaking up.
So, I'd recommend focusing on a description of the kind of community we want, instead of what we're trying to avoid; and postponing the enforcement language until later in the document, making it clear that enforcement only comes through (somewhat wide) deliberation of trusted community members (and, preferably, also after engagement with the offending party).
This way, we can hopefully instill trust in our CoC as a process, rather than a set of rules.
That sounds quite good to me. The process at a high level (for all but the most severe cases) should be something like:
1. complaint 2. reasonable discussion/feedback 3. mediation (if feedback didn't help) 4. enforcement via transparent decision by CoC committee (if mediation failed)
Yes, I like that list a lot. Although, I was proposing in the Jupyter discussion, that informal mediation be triggered really early, to help people get over the feeling of being isolated, that can easily arise in on-line communication - see : https://github.com/jupyter/governance/pull/23#issuecomment-269352416 . This was partly based on my reading of [1] (see quote), which suggested that one reason that women can find online forums intimidating is the lack of a mentor to guide them through the thickets of unfamiliar jargon, habits, and cliques. And partly because, having read that, I realized I felt the same way.
And not what some people may be afraid of, and sometimes actually happens in practice: 1. complaint 2. enforcement
For a new CoC draft, taking most of the Apache doc and tacking the more rules/enforcement oriented content of the Contributor Covenant onto the end seems like a good starting point.
Yes, I agree with that too ... :)
Hi all, here is a new version of the CoC taking this approach: https://github.com/scipy/scipy/pull/7963
Please have a look and comment. Higher level discussion better on this list, detailed textual comments on the PR itself.
Cheers, Ralf
Cheers,
Matthew
[1] https://suegardner.org/2011/02/19/nine-reasons-why-women-dont-edit-wikipedia...
""" The few times I’ve touched wikipedia, I’ve been struck by how isolating it can feel. It’s a very fend for yourself kind of place for me. Anywhere else online, my first impulse is to put out feelers. I make friends, ask for links to FAQs and guides, and inevitably someone takes me under their wing and shows me the ropes of whatever niche culture I’m obsessed with that month. """ _______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev
On Tue, Oct 3, 2017 at 12:28 AM, Bennet Fauber <bennet@umich.edu> wrote:
I am more a lurker than a contributor, but I would like to suggest caution with respect to item #5 in the proposed CoC.
+5. Be concise. Keep in mind that what you write once will be read by hundreds + of persons. Writing a short email means people can understand the + conversation as efficiently as possible. Short emails should always strive + to be empathetic, welcoming, friendly and patient. When a long explanation + is necessary, consider adding a summary.
I suggest that you should stress more that people should strive for clarity and completeness, and then say that brief and comprehensive is the desired goal. I think you're leaning on short too hard, and that will encourage incomplete more than real concision.
There are my reasons: 1) one person's concise could well be another's incomplete. 2) There are many, many terms that have more than one use, or that have different meanings in different contexts, or may have connotations; sometimes being concise leads to use of seemingly unambiguous terms that do turn out to be ambiguous.
For those who would reply that the definition of 'concise' implies completeness, as in the definition given:
giving a lot of information clearly and in a few words; brief but comprehensive.
In popular speech, and to those who may have been over-exposed to some kinds of management, concise is more likely to be interpreted as 'abbreviated', which highlights my second point above. I myself often interpret 'concise' to mean 'short' and often 'abbreviated', because that is what I have (alas) become accustomed to in my work environment.
Language evolved to have a lot of redundancy built into it for a reason. Stripping it of too much is as bad as including too much.
I hope I was sufficiently concise. ;-)
I agree with the general idea. Concise emails can be very intimidating, as in "it's so obvious you are wrong I can't be bothered to explain why". It's can also be an alienating sign, as in "I'm so senior here that there is no need for me to explain my reasoning". Maybe a better way to put it, is something like "Try to help your audience; your email will be read by hundreds of people, and many people will read only a few lines to decide if they are interested. Do you best to get to the point as fast as you can, so people can see what the email will be about. It is often useful to put a summary of a few lines at the top and then explain your reasoning in more depth below, for people who want to learn more." We could point to a few good examples. Cheers, Matthew
Matthew, Yes, precisely. I think this is in keeping with the desire to provide a positive tone, suggestive of desired behavior.
"Try to help your audience; your email will be read by hundreds of people, and many people will read only a few lines to decide if they are interested. Do you best to get to the point as fast as you can, so people can see what the email will be about. It is often useful to put a summary of a few lines at the top and then explain your reasoning in more depth below, for people who want to learn more." We could point to a few good examples.
I hope this modification gets closer to convergence. Help your audience. Your email will be read by hundreds of people. You may find summarizing at the beginning and providing fuller explanation of your reasoning below helpful, to yourself as well as your readers. Many people will scan the first few lines to see if the message is pertinent to their interests and expertise. Help them and future readers who may be sifting hundreds of search engine hits. See <URL> for a few select examples. On Tue, Oct 3, 2017 at 5:13 AM, Matthew Brett <matthew.brett@gmail.com> wrote:
On Tue, Oct 3, 2017 at 12:28 AM, Bennet Fauber <bennet@umich.edu> wrote:
I am more a lurker than a contributor, but I would like to suggest caution with respect to item #5 in the proposed CoC.
+5. Be concise. Keep in mind that what you write once will be read by hundreds + of persons. Writing a short email means people can understand the + conversation as efficiently as possible. Short emails should always strive + to be empathetic, welcoming, friendly and patient. When a long explanation + is necessary, consider adding a summary.
I suggest that you should stress more that people should strive for clarity and completeness, and then say that brief and comprehensive is the desired goal. I think you're leaning on short too hard, and that will encourage incomplete more than real concision.
There are my reasons: 1) one person's concise could well be another's incomplete. 2) There are many, many terms that have more than one use, or that have different meanings in different contexts, or may have connotations; sometimes being concise leads to use of seemingly unambiguous terms that do turn out to be ambiguous.
For those who would reply that the definition of 'concise' implies completeness, as in the definition given:
giving a lot of information clearly and in a few words; brief but comprehensive.
In popular speech, and to those who may have been over-exposed to some kinds of management, concise is more likely to be interpreted as 'abbreviated', which highlights my second point above. I myself often interpret 'concise' to mean 'short' and often 'abbreviated', because that is what I have (alas) become accustomed to in my work environment.
Language evolved to have a lot of redundancy built into it for a reason. Stripping it of too much is as bad as including too much.
I hope I was sufficiently concise. ;-)
I agree with the general idea. Concise emails can be very intimidating, as in "it's so obvious you are wrong I can't be bothered to explain why". It's can also be an alienating sign, as in "I'm so senior here that there is no need for me to explain my reasoning".
Maybe a better way to put it, is something like "Try to help your audience; your email will be read by hundreds of people, and many people will read only a few lines to decide if they are interested. Do you best to get to the point as fast as you can, so people can see what the email will be about. It is often useful to put a summary of a few lines at the top and then explain your reasoning in more depth below, for people who want to learn more." We could point to a few good examples.
Cheers,
Matthew _______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev
While I agree with Bennet and Matthew, I think the item should sound as much as its importance. If it starts to sound like a Terms and Conditions text it would defeat the purpose in my opinion. I would go along the lines of Help your audience by keeping the discussion focused. Your email will be read by hundreds of people on different media (including search engine hits). Many can only afford to skim through the mails to decide whether the subject is related to their expertise. Placing a brief summary is a good practice if the content does not allow for shortening. On the other hand, this should not be taken as a basis for terseness. "Things should be as simple as possible but not simpler." By the way, I think the numbering is off at item 3. On Tue, Oct 3, 2017 at 1:48 PM, Bennet Fauber <bennet@umich.edu> wrote:
Matthew,
Yes, precisely. I think this is in keeping with the desire to provide a positive tone, suggestive of desired behavior.
"Try to help your audience; your email will be read by hundreds of people, and many people will read only a few lines to decide if they are interested. Do you best to get to the point as fast as you can, so people can see what the email will be about. It is often useful to put a summary of a few lines at the top and then explain your reasoning in more depth below, for people who want to learn more." We could point to a few good examples.
I hope this modification gets closer to convergence.
Help your audience. Your email will be read by hundreds of people. You may find summarizing at the beginning and providing fuller explanation of your reasoning below helpful, to yourself as well as your readers. Many people will scan the first few lines to see if the message is pertinent to their interests and expertise. Help them and future readers who may be sifting hundreds of search engine hits. See <URL> for a few select examples.
On Tue, Oct 3, 2017 at 5:13 AM, Matthew Brett <matthew.brett@gmail.com> wrote:
On Tue, Oct 3, 2017 at 12:28 AM, Bennet Fauber <bennet@umich.edu> wrote:
I am more a lurker than a contributor, but I would like to suggest caution with respect to item #5 in the proposed CoC.
+5. Be concise. Keep in mind that what you write once will be read by hundreds + of persons. Writing a short email means people can understand the + conversation as efficiently as possible. Short emails should always strive + to be empathetic, welcoming, friendly and patient. When a long explanation + is necessary, consider adding a summary.
I suggest that you should stress more that people should strive for clarity and completeness, and then say that brief and comprehensive is the desired goal. I think you're leaning on short too hard, and that will encourage incomplete more than real concision.
There are my reasons: 1) one person's concise could well be another's incomplete. 2) There are many, many terms that have more than one use, or that have different meanings in different contexts, or may have connotations; sometimes being concise leads to use of seemingly unambiguous terms that do turn out to be ambiguous.
For those who would reply that the definition of 'concise' implies completeness, as in the definition given:
giving a lot of information clearly and in a few words; brief but comprehensive.
In popular speech, and to those who may have been over-exposed to some kinds of management, concise is more likely to be interpreted as 'abbreviated', which highlights my second point above. I myself often interpret 'concise' to mean 'short' and often 'abbreviated', because that is what I have (alas) become accustomed to in my work environment.
Language evolved to have a lot of redundancy built into it for a reason. Stripping it of too much is as bad as including too much.
I hope I was sufficiently concise. ;-)
I agree with the general idea. Concise emails can be very intimidating, as in "it's so obvious you are wrong I can't be bothered to explain why". It's can also be an alienating sign, as in "I'm so senior here that there is no need for me to explain my reasoning".
Maybe a better way to put it, is something like "Try to help your audience; your email will be read by hundreds of people, and many people will read only a few lines to decide if they are interested. Do you best to get to the point as fast as you can, so people can see what the email will be about. It is often useful to put a summary of a few lines at the top and then explain your reasoning in more depth below, for people who want to learn more." We could point to a few good examples.
Cheers,
Matthew _______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev
SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev
Hi, On Tue, Oct 3, 2017 at 1:07 PM, Ilhan Polat <ilhanpolat@gmail.com> wrote:
While I agree with Bennet and Matthew, I think the item should sound as much as its importance. If it starts to sound like a Terms and Conditions text it would defeat the purpose in my opinion. I would go along the lines of
Help your audience by keeping the discussion focused. Your email will be read by hundreds of people on different media (including search engine hits). Many can only afford to skim through the mails to decide whether the subject is related to their expertise. Placing a brief summary is a good practice if the content does not allow for shortening. On the other hand, this should not be taken as a basis for terseness. "Things should be as simple as possible but not simpler."
By the way, I think the numbering is off at item 3.
Terms and Conditions is rather in the eye of beholder though. Just for example, if you run these last 3 versions though readable.io you get grade level reading scores (lower = easier to read) of: Me: 4.4 Bennet: 6.6 Ilhan: 9.2 I highly recommend readable.io - I didn't run it on my stuff until just now, but I generally find it gives useful suggestions on improving clarity and readability. Cheers, Matthew
Ah come on. What is this condescending nonsense "A score of around 10-12 is roughly the reading level on completion of high school. Text to be read by the general public should aim for a grade level of around 8."? On Tue, Oct 3, 2017 at 2:45 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
While I agree with Bennet and Matthew, I think the item should sound as much as its importance. If it starts to sound like a Terms and Conditions text it would defeat the purpose in my opinion. I would go along the lines of
Help your audience by keeping the discussion focused. Your email will be read by hundreds of people on different media (including search engine hits). Many can only afford to skim through the mails to decide whether
On Tue, Oct 3, 2017 at 1:07 PM, Ilhan Polat <ilhanpolat@gmail.com> wrote: the
subject is related to their expertise. Placing a brief summary is a good practice if the content does not allow for shortening. On the other hand, this should not be taken as a basis for terseness. "Things should be as simple as possible but not simpler."
By the way, I think the numbering is off at item 3.
Terms and Conditions is rather in the eye of beholder though.
Just for example, if you run these last 3 versions though readable.io you get grade level reading scores (lower = easier to read) of:
Me: 4.4 Bennet: 6.6 Ilhan: 9.2
I highly recommend readable.io - I didn't run it on my stuff until just now, but I generally find it gives useful suggestions on improving clarity and readability.
Cheers,
Matthew _______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev
I should have probably put a smiley in the end. I mean it quite lightly by the way. On Tue, Oct 3, 2017 at 5:16 PM, Ilhan Polat <ilhanpolat@gmail.com> wrote:
Ah come on. What is this condescending nonsense "A score of around 10-12 is roughly the reading level on completion of high school. Text to be read by the general public should aim for a grade level of around 8."?
On Tue, Oct 3, 2017 at 2:45 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
While I agree with Bennet and Matthew, I think the item should sound as much as its importance. If it starts to sound like a Terms and Conditions text it would defeat the purpose in my opinion. I would go along the lines of
Help your audience by keeping the discussion focused. Your email will be read by hundreds of people on different media (including search engine hits). Many can only afford to skim through the mails to decide whether
On Tue, Oct 3, 2017 at 1:07 PM, Ilhan Polat <ilhanpolat@gmail.com> wrote: the
subject is related to their expertise. Placing a brief summary is a good practice if the content does not allow for shortening. On the other hand, this should not be taken as a basis for terseness. "Things should be as simple as possible but not simpler."
By the way, I think the numbering is off at item 3.
Terms and Conditions is rather in the eye of beholder though.
Just for example, if you run these last 3 versions though readable.io you get grade level reading scores (lower = easier to read) of:
Me: 4.4 Bennet: 6.6 Ilhan: 9.2
I highly recommend readable.io - I didn't run it on my stuff until just now, but I generally find it gives useful suggestions on improving clarity and readability.
Cheers,
Matthew _______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev
On Tue, Oct 3, 2017 at 4:16 PM, Ilhan Polat <ilhanpolat@gmail.com> wrote:
Ah come on. What is this condescending nonsense "A score of around 10-12 is roughly the reading level on completion of high school. Text to be read by the general public should aim for a grade level of around 8."?
I am sorry, I didn't mean it to be condescending. I just mean that most people feel that text they write is clearer than text other people write, on average, for the obvious reason that we tend to understand the things that we say better than things other people say. So I wasn't claiming that the metrics made my text better than your text, only that it's difficult to be objective about what is clear - or - as you said - what reads like "terms and conditions". As for the grade level - have a look at the comments that readability.io gives - it's good advice about avoiding long words and long sentences if possible (it usually is) and the passive tense. Text with a low grade level, when well written, does not seem patronizing, but is easy to read and say - conveying the same meaning with less effort to the reader. Best, Matthew
I guess my second mail didn't make it to the server for some reason. I've written: "I should have probably put a smiley in the end. I mean it quite lightly by the way. " No problem at all, Matthew for one I'm not a native speaker and second you guys probably have seen more conflicts than I ever did. I just wanted to have the text a bit less formal. Best, On Tue, Oct 3, 2017 at 6:26 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
On Tue, Oct 3, 2017 at 4:16 PM, Ilhan Polat <ilhanpolat@gmail.com> wrote:
Ah come on. What is this condescending nonsense "A score of around 10-12 is roughly the reading level on completion of high school. Text to be read by the general public should aim for a grade level of around 8."?
I am sorry, I didn't mean it to be condescending. I just mean that most people feel that text they write is clearer than text other people write, on average, for the obvious reason that we tend to understand the things that we say better than things other people say. So I wasn't claiming that the metrics made my text better than your text, only that it's difficult to be objective about what is clear - or - as you said - what reads like "terms and conditions".
As for the grade level - have a look at the comments that readability.io gives - it's good advice about avoiding long words and long sentences if possible (it usually is) and the passive tense. Text with a low grade level, when well written, does not seem patronizing, but is easy to read and say - conveying the same meaning with less effort to the reader.
Best,
Matthew _______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev
Hi, On Tue, Oct 3, 2017 at 6:47 PM, Ilhan Polat <ilhanpolat@gmail.com> wrote:
I guess my second mail didn't make it to the server for some reason. I've written:
"I should have probably put a smiley in the end. I mean it quite lightly by the way. "
No problem at all, Matthew for one I'm not a native speaker and second you guys probably have seen more conflicts than I ever did. I just wanted to have the text a bit less formal.
Sure - no problem from my side - I completely agree that less formal is better ... Cheers, Matthew
On Wed, Oct 4, 2017 at 6:51 AM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Tue, Oct 3, 2017 at 6:47 PM, Ilhan Polat <ilhanpolat@gmail.com> wrote:
I guess my second mail didn't make it to the server for some reason. I've written:
"I should have probably put a smiley in the end. I mean it quite lightly by the way. "
No problem at all, Matthew for one I'm not a native speaker and second you guys probably have seen more conflicts than I ever did. I just wanted to have the text a bit less formal.
Sure - no problem from my side - I completely agree that less formal is better ...
Thanks Bennett, Matthew and Ilhan. I agree that "be concise" can be misunderstood if not worded right. Stefan commented on the PR "Points 5, 6, 7, and 8 seem less relevant to me, and less tied to principles. Consider cutting for the sake of brevity?". I think that's a good point, so would like to go with that. It also means we don't have to choose between your three versions of point 5:) Cheers, Ralf
Cheers,
Matthew _______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev
On Thu, Oct 5, 2017 at 6:42 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Wed, Oct 4, 2017 at 6:51 AM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Tue, Oct 3, 2017 at 6:47 PM, Ilhan Polat <ilhanpolat@gmail.com> wrote:
I guess my second mail didn't make it to the server for some reason. I've written:
"I should have probably put a smiley in the end. I mean it quite lightly by the way. "
No problem at all, Matthew for one I'm not a native speaker and second you guys probably have seen more conflicts than I ever did. I just wanted to have the text a bit less formal.
Sure - no problem from my side - I completely agree that less formal is better ...
Thanks Bennett, Matthew and Ilhan. I agree that "be concise" can be misunderstood if not worded right.
Stefan commented on the PR "Points 5, 6, 7, and 8 seem less relevant to me, and less tied to principles. Consider cutting for the sake of brevity?". I think that's a good point, so would like to go with that. It also means we don't have to choose between your three versions of point 5:)
Excellent outcome - more concise :) Cheers, Matthew
On Fri, Oct 6, 2017 at 7:05 AM, Matthew Brett <matthew.brett@gmail.com> wrote:
On Thu, Oct 5, 2017 at 6:42 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Wed, Oct 4, 2017 at 6:51 AM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Tue, Oct 3, 2017 at 6:47 PM, Ilhan Polat <ilhanpolat@gmail.com>
I guess my second mail didn't make it to the server for some reason. I've written:
"I should have probably put a smiley in the end. I mean it quite
wrote: lightly
by the way. "
No problem at all, Matthew for one I'm not a native speaker and second you guys probably have seen more conflicts than I ever did. I just wanted to have the text a bit less formal.
Sure - no problem from my side - I completely agree that less formal is better ...
Thanks Bennett, Matthew and Ilhan. I agree that "be concise" can be misunderstood if not worded right.
Stefan commented on the PR "Points 5, 6, 7, and 8 seem less relevant to me, and less tied to principles. Consider cutting for the sake of brevity?". I think that's a good point, so would like to go with that. It also means we don't have to choose between your three versions of point 5:)
Excellent outcome - more concise :)
Hi all, there haven't been more comments on the PR in the last 10 days and so far it seems everyone is happy. I said earlier that I'd organise a public conference call in order to give another venue for input, and I'd still like to do that. So here's a proposal: Thursday 19 Oct at 7pm UCT on Google Hangouts We've puzzled with time zones before, the best one was very early morning in Australia and late evening in Russia. This time will be 6am in Sydney, 10pm in Moscow, 8pm CET, 3pm US east cost, noon US west coast. Also, it would be great to get a few volunteers for the CoC committee. Any takers? Cheers, Ralf
On Mon, Oct 16, 2017 at 1:51 AM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
Hi all, there haven't been more comments on the PR in the last 10 days and so far it seems everyone is happy. I said earlier that I'd organise a public conference call in order to give another venue for input, and I'd still like to do that. So here's a proposal:
Thursday 19 Oct at 7pm UCT on Google Hangouts
We've puzzled with time zones before, the best one was very early morning in Australia and late evening in Russia. This time will be 6am in Sydney, 10pm in Moscow, 8pm CET, 3pm US east cost, noon US west coast.
I can attend the first half hour, anyway... and I'll try to comment on the PR before then too.
Also, it would be great to get a few volunteers for the CoC committee. Any takers?
Sure. -n -- Nathaniel J. Smith -- https://vorpus.org
On Mon, Oct 16, 2017 at 10:15 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Mon, Oct 16, 2017 at 1:51 AM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
Hi all, there haven't been more comments on the PR in the last 10 days
so far it seems everyone is happy. I said earlier that I'd organise a
conference call in order to give another venue for input, and I'd still
and public like
to do that. So here's a proposal:
Thursday 19 Oct at 7pm UCT on Google Hangouts
We've puzzled with time zones before, the best one was very early morning in Australia and late evening in Russia. This time will be 6am in Sydney, 10pm in Moscow, 8pm CET, 3pm US east cost, noon US west coast.
I can attend the first half hour, anyway... and I'll try to comment on the PR before then too.
Also, it would be great to get a few volunteers for the CoC committee. Any takers?
Sure.
Thanks! Anyone else? Note that (I think) it's not essential that all committee members are part of the core developer team. If you're part of the community and are interested in being on this commitee, please let us know (offline questions or expressions of interest also welcome). If you have experience with CoCs and/or can increase the diversity of experiences and viewpoints on the committee, that would be doubly welcome. Cheers, Ralf
-n
-- Nathaniel J. Smith -- https://vorpus.org _______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev
I put the Thursday meeting on my calendar -- should be able to listen in at least. Tyler On 17 October 2017 at 00:18, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Mon, Oct 16, 2017 at 10:15 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Mon, Oct 16, 2017 at 1:51 AM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
Hi all, there haven't been more comments on the PR in the last 10 days
so far it seems everyone is happy. I said earlier that I'd organise a
conference call in order to give another venue for input, and I'd still
and public like
to do that. So here's a proposal:
Thursday 19 Oct at 7pm UCT on Google Hangouts
We've puzzled with time zones before, the best one was very early morning in Australia and late evening in Russia. This time will be 6am in Sydney, 10pm in Moscow, 8pm CET, 3pm US east cost, noon US west coast.
I can attend the first half hour, anyway... and I'll try to comment on the PR before then too.
Also, it would be great to get a few volunteers for the CoC committee. Any takers?
Sure.
Thanks!
Anyone else? Note that (I think) it's not essential that all committee members are part of the core developer team. If you're part of the community and are interested in being on this commitee, please let us know (offline questions or expressions of interest also welcome). If you have experience with CoCs and/or can increase the diversity of experiences and viewpoints on the committee, that would be doubly welcome.
Cheers, Ralf
-n
-- Nathaniel J. Smith -- https://vorpus.org _______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev
Hi, On Tue, Oct 17, 2017 at 7:18 AM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Mon, Oct 16, 2017 at 10:15 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Mon, Oct 16, 2017 at 1:51 AM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
Hi all, there haven't been more comments on the PR in the last 10 days and so far it seems everyone is happy. I said earlier that I'd organise a public conference call in order to give another venue for input, and I'd still like to do that. So here's a proposal:
Thursday 19 Oct at 7pm UCT on Google Hangouts
We've puzzled with time zones before, the best one was very early morning in Australia and late evening in Russia. This time will be 6am in Sydney, 10pm in Moscow, 8pm CET, 3pm US east cost, noon US west coast.
I can attend the first half hour, anyway... and I'll try to comment on the PR before then too.
Also, it would be great to get a few volunteers for the CoC committee. Any takers?
Sure.
Thanks!
Anyone else? Note that (I think) it's not essential that all committee members are part of the core developer team. If you're part of the community and are interested in being on this commitee, please let us know (offline questions or expressions of interest also welcome). If you have experience with CoCs and/or can increase the diversity of experiences and viewpoints on the committee, that would be doubly welcome.
I can make it, and would like to join. Cheers, Matthew
I can make it. On Wed, Oct 18, 2017 at 11:58 AM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Tue, Oct 17, 2017 at 7:18 AM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Mon, Oct 16, 2017 at 10:15 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Mon, Oct 16, 2017 at 1:51 AM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
Hi all, there haven't been more comments on the PR in the last 10 days and so far it seems everyone is happy. I said earlier that I'd organise a public conference call in order to give another venue for input, and I'd
still
like to do that. So here's a proposal:
Thursday 19 Oct at 7pm UCT on Google Hangouts
We've puzzled with time zones before, the best one was very early morning in Australia and late evening in Russia. This time will be 6am in Sydney, 10pm in Moscow, 8pm CET, 3pm US east cost, noon US west coast.
I can attend the first half hour, anyway... and I'll try to comment on the PR before then too.
Also, it would be great to get a few volunteers for the CoC committee. Any takers?
Sure.
Thanks!
Anyone else? Note that (I think) it's not essential that all committee members are part of the core developer team. If you're part of the community and are interested in being on this commitee, please let us know (offline questions or expressions of interest also welcome). If you have experience with CoCs and/or can increase the diversity of experiences and viewpoints on the committee, that would be doubly welcome.
I can make it, and would like to join.
Cheers,
Matthew _______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev
-- Matt Haberland Assistant Adjunct Professor in the Program in Computing Department of Mathematics 7620E Math Sciences Building, UCLA
Hi, Back to the code of conduct discussion, Nathaniel has raised a pertinent theme over at the Scipy PR - main comment at: https://github.com/scipy/scipy/pull/7963#discussion_r145580285 Nathaniel's basic point, as I understand it, is that one common type of behavior that we should be able to deal with, is flagrant and aggressive abuse, likely from people otherwise not involved in Scipy. He gives this example "Last night someone logged into the #scipy channel on Freenode and started pasting racial slurs in giant letters.". Nathaniel then goes on to argue that the language and procedures in the CoC as stands don't apply to that case. I think that's reasonable, but I think we have to be careful to distinguish: 1) obvious flagrant abuse, likely from someone who does not contribute, possibly from someone who does contribute who is having a breakdown of some sort and 2) discussions that started in good faith and have gone out of control. It's true that the current code of conduct is aimed more or less squarely at the second. I don't personally think we're going to have too much trouble distinguishing these two cases, so I'm going to suggest that, instead of switching the doc to aiming at case 1 rather than case 2, we have a safely-valve mechanism for case 1. This would go something like: """ As a special case, we know that it is painfully common for internet communication to start at or devolve into obvious and flagrant abuse including violent, racist and sexist language. In the specific case of violent, racist or sexist language, these {named moderators} will use the following procedure: * immediately disconnect the person from all Scipy communication channels; * if the originator appears to be a previous contributor, the moderator may try to contact the contributor by some other means to check whether their account has been hacked. * if the originator is in fact a previous contributor, and the contributor wants to be reconnected to the Scipy channels, then {consider some cooling off period, an agreement not to repeat the behavior, and email moderation. A previous contributor also has the right to an appeal to the code of conduct committee}. * in every case, the moderator should make a reasonable effort to contact the originator, and tell them specifically how their language qualifies as "violent, racist or sexist language", and they should copy this explanation to the code of conduct committee. The code of conduct committee should formally review and sign off on these cases every year to make sure this mechanism is not being used to control ordinary heated disagreement. """ I've argued before [1] that the best way to think about these documents, is in terms of specific use-cases. In Nathaniel's case above, I think it's fairly obvious how the mechanism above would work. Next we consider the famous case of the sexist joke on the Ubuntu mailing list [2]. I think that would also qualify for the mechanism above, but where we would expect the resolution to be that the originator would have to agree not to post sexist material to that list, and be moderated for a while, Last we consider the SpacedGirl Software Carpentry Case [1], where this procedure could not reasonably be invoked, and the rest of the current code of conduct would apply. Cheers, Matthew [1] https://github.com/jupyter/governance/pull/23#issuecomment-269244281 [2] http://geekfeminism.wikia.com/wiki/Ubuntu_Code_of_Conduct_incident
On Thu, Oct 19, 2017 at 2:11 AM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
Back to the code of conduct discussion, Nathaniel has raised a pertinent theme over at the Scipy PR - main comment at:
https://github.com/scipy/scipy/pull/7963#discussion_r145580285
Nathaniel's basic point, as I understand it, is that one common type of behavior that we should be able to deal with, is flagrant and aggressive abuse, likely from people otherwise not involved in Scipy. He gives this example "Last night someone logged into the #scipy channel on Freenode and started pasting racial slurs in giant letters.".
Nathaniel then goes on to argue that the language and procedures in the CoC as stands don't apply to that case.
I think that's reasonable, but I think we have to be careful to distinguish:
1) obvious flagrant abuse, likely from someone who does not contribute, possibly from someone who does contribute who is having a breakdown of some sort and 2) discussions that started in good faith and have gone out of control.
It's true that the current code of conduct is aimed more or less squarely at the second.
I don't personally think we're going to have too much trouble distinguishing these two cases, so I'm going to suggest that, instead of switching the doc to aiming at case 1 rather than case 2, we have a safely-valve mechanism for case 1. This would go something like:
""" As a special case,
Your suggestions all make sense, but I suggest not calling one of possible types of cases a "special case". Ralf we know that it is painfully common for internet
communication to start at or devolve into obvious and flagrant abuse including violent, racist and sexist language. In the specific case of violent, racist or sexist language, these {named moderators} will use the following procedure:
* immediately disconnect the person from all Scipy communication channels; * if the originator appears to be a previous contributor, the moderator may try to contact the contributor by some other means to check whether their account has been hacked. * if the originator is in fact a previous contributor, and the contributor wants to be reconnected to the Scipy channels, then {consider some cooling off period, an agreement not to repeat the behavior, and email moderation. A previous contributor also has the right to an appeal to the code of conduct committee}. * in every case, the moderator should make a reasonable effort to contact the originator, and tell them specifically how their language qualifies as "violent, racist or sexist language", and they should copy this explanation to the code of conduct committee. The code of conduct committee should formally review and sign off on these cases every year to make sure this mechanism is not being used to control ordinary heated disagreement. """
I've argued before [1] that the best way to think about these documents, is in terms of specific use-cases. In Nathaniel's case above, I think it's fairly obvious how the mechanism above would work. Next we consider the famous case of the sexist joke on the Ubuntu mailing list [2]. I think that would also qualify for the mechanism above, but where we would expect the resolution to be that the originator would have to agree not to post sexist material to that list, and be moderated for a while, Last we consider the SpacedGirl Software Carpentry Case [1], where this procedure could not reasonably be invoked, and the rest of the current code of conduct would apply.
Cheers,
Matthew
[1] https://github.com/jupyter/governance/pull/23#issuecomment-269244281 [2] http://geekfeminism.wikia.com/wiki/Ubuntu_Code_of_Conduct_incident _______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev
On Wed, Oct 18, 2017 at 7:59 PM, Matt Haberland <haberland@ucla.edu> wrote:
I can make it.
On Wed, Oct 18, 2017 at 11:58 AM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Tue, Oct 17, 2017 at 7:18 AM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Mon, Oct 16, 2017 at 10:15 PM, Nathaniel Smith <njs@pobox.com>
wrote:
On Mon, Oct 16, 2017 at 1:51 AM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
Hi all, there haven't been more comments on the PR in the last 10
days
and so far it seems everyone is happy. I said earlier that I'd organise a public conference call in order to give another venue for input, and I'd still like to do that. So here's a proposal:
Thursday 19 Oct at 7pm UCT on Google Hangouts
Link for the call starting in an hour: https://hangouts.google.com/call/KRDkcjS3HQl-LMI6hbpzAAEM This will work best with Chrome. Recent versions of Firefox, IE, etc. will also work but keep in mind that outdated browser versions may not connect. Cheers, Ralf
We've puzzled with time zones before, the best one was very early morning in Australia and late evening in Russia. This time will be 6am in
Sydney,
10pm in Moscow, 8pm CET, 3pm US east cost, noon US west coast.
I can attend the first half hour, anyway... and I'll try to comment on the PR before then too.
Also, it would be great to get a few volunteers for the CoC committee. Any takers?
Sure.
Thanks!
Anyone else? Note that (I think) it's not essential that all committee members are part of the core developer team. If you're part of the community and are interested in being on this commitee, please let us know (offline questions or expressions of interest also welcome). If you have experience with CoCs and/or can increase the diversity of experiences and viewpoints on the committee, that would be doubly welcome.
I can make it, and would like to join.
Cheers,
Matthew _______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev
-- Matt Haberland Assistant Adjunct Professor in the Program in Computing Department of Mathematics 7620E Math Sciences Building, UCLA
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev
Sorry I might be a bit late, IT issues (windows machine:( ) Sent from my iPhone
On 20/10/2017, at 7:06 AM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Wed, Oct 18, 2017 at 7:59 PM, Matt Haberland <haberland@ucla.edu> wrote: I can make it.
On Wed, Oct 18, 2017 at 11:58 AM, Matthew Brett <matthew.brett@gmail.com> wrote: Hi,
On Tue, Oct 17, 2017 at 7:18 AM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Mon, Oct 16, 2017 at 10:15 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Mon, Oct 16, 2017 at 1:51 AM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
Hi all, there haven't been more comments on the PR in the last 10 days and so far it seems everyone is happy. I said earlier that I'd organise a public conference call in order to give another venue for input, and I'd still like to do that. So here's a proposal:
Thursday 19 Oct at 7pm UCT on Google Hangouts
Link for the call starting in an hour: https://hangouts.google.com/call/KRDkcjS3HQl-LMI6hbpzAAEM
This will work best with Chrome. Recent versions of Firefox, IE, etc. will also work but keep in mind that outdated browser versions may not connect.
Cheers, Ralf
We've puzzled with time zones before, the best one was very early morning in Australia and late evening in Russia. This time will be 6am in Sydney, 10pm in Moscow, 8pm CET, 3pm US east cost, noon US west coast.
I can attend the first half hour, anyway... and I'll try to comment on the PR before then too.
Also, it would be great to get a few volunteers for the CoC committee. Any takers?
Sure.
Thanks!
Anyone else? Note that (I think) it's not essential that all committee members are part of the core developer team. If you're part of the community and are interested in being on this commitee, please let us know (offline questions or expressions of interest also welcome). If you have experience with CoCs and/or can increase the diversity of experiences and viewpoints on the committee, that would be doubly welcome.
I can make it, and would like to join.
Cheers,
Matthew _______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev
-- Matt Haberland Assistant Adjunct Professor in the Program in Computing Department of Mathematics 7620E Math Sciences Building, UCLA
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev
Hi, I tried to distill the results of the discussion into a PR to Ralf's PR: https://github.com/rgommers/scipy/pull/14 Nathaniel - I probably didn't convey this well over the broken line we were on, but I do fully accept that we have to be careful about subtle discrimination, against women in particular, and I have added that as a specific concern in the PR, but please feel free to insist if I haven't captured what you meant. Cheers, Matthew
On Fri, Oct 20, 2017 at 12:00 AM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
I tried to distill the results of the discussion into a PR to Ralf's PR:
https://github.com/rgommers/scipy/pull/14
Nathaniel - I probably didn't convey this well over the broken line we were on, but I do fully accept that we have to be careful about subtle discrimination, against women in particular, and I have added that as a specific concern in the PR, but please feel free to insist if I haven't captured what you meant.
Also - here is the work I was referring to about the uses to which labeling is put to in order to damage and exclude: http://kwesthues.com/diffprof.htm In this case above it is 'difficult' as applied to a professor, but I'd add 'asshole' or 'jerk' as applied to a contributor. Cheers, Matthew
On Thu, Oct 19, 2017 at 4:00 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
I tried to distill the results of the discussion into a PR to Ralf's PR:
Great, thanks Matthew. That PR is related to the longest discussion we had. Here I'll also briefly summarize the other things we discussed: 1. A question on the CoC PR on whether we need a separate CoC committee or can make do with either a single person or letting the SciPy steering committee handle the job. The outcome was that we do want a CoC committee, ideally 3-5 people in size. 2. The discussion about different cases that Matthew's PR responds to. Discussion started from this comment: https://github.com/scipy/scipy/pull/7963#discussion_r145582715, and a couple of previous emails on this mailing list also were related to that comment. 3. Timeline for merging the CoC. I will incorporate Matthew's PR and address other open comments tonight. Then I'll be offline until Monday evening. Hopefully by then the remaining points for discussion have been converged. I'd like to merge the CoC on Tuesday and release 1.0 on Wednesday. Cheers, Ralf
Nathaniel - I probably didn't convey this well over the broken line we were on, but I do fully accept that we have to be careful about subtle discrimination, against women in particular, and I have added that as a specific concern in the PR, but please feel free to insist if I haven't captured what you meant.
Cheers,
Matthew _______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev
On Fri, Oct 20, 2017 at 6:47 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Thu, Oct 19, 2017 at 4:00 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
I tried to distill the results of the discussion into a PR to Ralf's PR:
Great, thanks Matthew.
That PR is related to the longest discussion we had. Here I'll also briefly summarize the other things we discussed:
1. A question on the CoC PR on whether we need a separate CoC committee or can make do with either a single person or letting the SciPy steering committee handle the job. The outcome was that we do want a CoC committee, ideally 3-5 people in size.
2. The discussion about different cases that Matthew's PR responds to. Discussion started from this comment: https://github.com/scipy/ scipy/pull/7963#discussion_r145582715, and a couple of previous emails on this mailing list also were related to that comment.
3. Timeline for merging the CoC. I will incorporate Matthew's PR and address other open comments tonight. Then I'll be offline until Monday evening. Hopefully by then the remaining points for discussion have been converged. I'd like to merge the CoC on Tuesday and release 1.0 on Wednesday.
The CoC is now merged. Thanks everyone for the constructive discussion! Cheers, Ralf
Cheers, Ralf
Nathaniel - I probably didn't convey this well over the broken line we were on, but I do fully accept that we have to be careful about subtle discrimination, against women in particular, and I have added that as a specific concern in the PR, but please feel free to insist if I haven't captured what you meant.
Cheers,
Matthew _______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev
I can't make it on Thursday morning if that makes a difference to the timing. On 16 Oct 2017 7:52 pm, "Ralf Gommers" <ralf.gommers@gmail.com> wrote: On Fri, Oct 6, 2017 at 7:05 AM, Matthew Brett <matthew.brett@gmail.com> wrote:
On Thu, Oct 5, 2017 at 6:42 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Wed, Oct 4, 2017 at 6:51 AM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Tue, Oct 3, 2017 at 6:47 PM, Ilhan Polat <ilhanpolat@gmail.com>
I guess my second mail didn't make it to the server for some reason. I've written:
"I should have probably put a smiley in the end. I mean it quite
wrote: lightly
by the way. "
No problem at all, Matthew for one I'm not a native speaker and second you guys probably have seen more conflicts than I ever did. I just wanted to have the text a bit less formal.
Sure - no problem from my side - I completely agree that less formal is better ...
Thanks Bennett, Matthew and Ilhan. I agree that "be concise" can be misunderstood if not worded right.
Stefan commented on the PR "Points 5, 6, 7, and 8 seem less relevant to me, and less tied to principles. Consider cutting for the sake of brevity?". I think that's a good point, so would like to go with that. It also means we don't have to choose between your three versions of point 5:)
Excellent outcome - more concise :)
Hi all, there haven't been more comments on the PR in the last 10 days and so far it seems everyone is happy. I said earlier that I'd organise a public conference call in order to give another venue for input, and I'd still like to do that. So here's a proposal: Thursday 19 Oct at 7pm UCT on Google Hangouts We've puzzled with time zones before, the best one was very early morning in Australia and late evening in Russia. This time will be 6am in Sydney, 10pm in Moscow, 8pm CET, 3pm US east cost, noon US west coast. Also, it would be great to get a few volunteers for the CoC committee. Any takers? Cheers, Ralf _______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev
On Mon, Oct 16, 2017 at 10:28 PM, Andrew Nelson <andyfaff@gmail.com> wrote:
I can't make it on Thursday morning if that makes a difference to the timing.
Hi Andrew, it's Friday morning for you. Either way, doesn't make too much of a difference because I'm in New Zealand which is only 2 hours ahead of Australia. But we could shift it forward one or two hours if needed. Ralf
On 16 Oct 2017 7:52 pm, "Ralf Gommers" <ralf.gommers@gmail.com> wrote:
On Fri, Oct 6, 2017 at 7:05 AM, Matthew Brett <matthew.brett@gmail.com> wrote:
On Thu, Oct 5, 2017 at 6:42 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Wed, Oct 4, 2017 at 6:51 AM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Tue, Oct 3, 2017 at 6:47 PM, Ilhan Polat <ilhanpolat@gmail.com>
I guess my second mail didn't make it to the server for some reason. I've written:
"I should have probably put a smiley in the end. I mean it quite
wrote: lightly
by the way. "
No problem at all, Matthew for one I'm not a native speaker and second you guys probably have seen more conflicts than I ever did. I just wanted to have the text a bit less formal.
Sure - no problem from my side - I completely agree that less formal is better ...
Thanks Bennett, Matthew and Ilhan. I agree that "be concise" can be misunderstood if not worded right.
Stefan commented on the PR "Points 5, 6, 7, and 8 seem less relevant to me, and less tied to principles. Consider cutting for the sake of brevity?". I think that's a good point, so would like to go with that. It also means we don't have to choose between your three versions of point 5:)
Excellent outcome - more concise :)
Hi all, there haven't been more comments on the PR in the last 10 days and so far it seems everyone is happy. I said earlier that I'd organise a public conference call in order to give another venue for input, and I'd still like to do that. So here's a proposal:
Thursday 19 Oct at 7pm UCT on Google Hangouts
We've puzzled with time zones before, the best one was very early morning in Australia and late evening in Russia. This time will be 6am in Sydney, 10pm in Moscow, 8pm CET, 3pm US east cost, noon US west coast.
Also, it would be great to get a few volunteers for the CoC committee. Any takers?
Cheers, Ralf
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev
I'm travelling for work on Friday. On 16 Oct 2017 8:35 pm, "Ralf Gommers" <ralf.gommers@gmail.com> wrote: On Mon, Oct 16, 2017 at 10:28 PM, Andrew Nelson <andyfaff@gmail.com> wrote:
I can't make it on Thursday morning if that makes a difference to the timing.
Hi Andrew, it's Friday morning for you. Either way, doesn't make too much of a difference because I'm in New Zealand which is only 2 hours ahead of Australia. But we could shift it forward one or two hours if needed. Ralf
On 16 Oct 2017 7:52 pm, "Ralf Gommers" <ralf.gommers@gmail.com> wrote:
On Fri, Oct 6, 2017 at 7:05 AM, Matthew Brett <matthew.brett@gmail.com> wrote:
On Thu, Oct 5, 2017 at 6:42 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Wed, Oct 4, 2017 at 6:51 AM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Tue, Oct 3, 2017 at 6:47 PM, Ilhan Polat <ilhanpolat@gmail.com>
I guess my second mail didn't make it to the server for some reason. I've written:
"I should have probably put a smiley in the end. I mean it quite
wrote: lightly
by the way. "
No problem at all, Matthew for one I'm not a native speaker and second you guys probably have seen more conflicts than I ever did. I just wanted to have the text a bit less formal.
Sure - no problem from my side - I completely agree that less formal is better ...
Thanks Bennett, Matthew and Ilhan. I agree that "be concise" can be misunderstood if not worded right.
Stefan commented on the PR "Points 5, 6, 7, and 8 seem less relevant to me, and less tied to principles. Consider cutting for the sake of brevity?". I think that's a good point, so would like to go with that. It also means we don't have to choose between your three versions of point 5:)
Excellent outcome - more concise :)
Hi all, there haven't been more comments on the PR in the last 10 days and so far it seems everyone is happy. I said earlier that I'd organise a public conference call in order to give another venue for input, and I'd still like to do that. So here's a proposal:
Thursday 19 Oct at 7pm UCT on Google Hangouts
We've puzzled with time zones before, the best one was very early morning in Australia and late evening in Russia. This time will be 6am in Sydney, 10pm in Moscow, 8pm CET, 3pm US east cost, noon US west coast.
Also, it would be great to get a few volunteers for the CoC committee. Any takers?
Cheers, Ralf
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev
I can't make it on Thursday morning if that makes a difference to the timing. On 16 Oct 2017 7:52 pm, "Ralf Gommers" <ralf.gommers@gmail.com> wrote: On Fri, Oct 6, 2017 at 7:05 AM, Matthew Brett <matthew.brett@gmail.com> wrote:
On Thu, Oct 5, 2017 at 6:42 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Wed, Oct 4, 2017 at 6:51 AM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Tue, Oct 3, 2017 at 6:47 PM, Ilhan Polat <ilhanpolat@gmail.com>
I guess my second mail didn't make it to the server for some reason. I've written:
"I should have probably put a smiley in the end. I mean it quite
wrote: lightly
by the way. "
No problem at all, Matthew for one I'm not a native speaker and second you guys probably have seen more conflicts than I ever did. I just wanted to have the text a bit less formal.
Sure - no problem from my side - I completely agree that less formal is better ...
Thanks Bennett, Matthew and Ilhan. I agree that "be concise" can be misunderstood if not worded right.
Stefan commented on the PR "Points 5, 6, 7, and 8 seem less relevant to me, and less tied to principles. Consider cutting for the sake of brevity?". I think that's a good point, so would like to go with that. It also means we don't have to choose between your three versions of point 5:)
Excellent outcome - more concise :)
Hi all, there haven't been more comments on the PR in the last 10 days and so far it seems everyone is happy. I said earlier that I'd organise a public conference call in order to give another venue for input, and I'd still like to do that. So here's a proposal: Thursday 19 Oct at 7pm UCT on Google Hangouts We've puzzled with time zones before, the best one was very early morning in Australia and late evening in Russia. This time will be 6am in Sydney, 10pm in Moscow, 8pm CET, 3pm US east cost, noon US west coast. Also, it would be great to get a few volunteers for the CoC committee. Any takers? Cheers, Ralf _______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev
participants (12)
-
Andrew Nelson -
Bennet Fauber -
Charles R Harris -
Ilhan Polat -
Matt Haberland -
Matthew Brett -
Nathaniel Smith -
Pauli Virtanen -
Ralf Gommers -
ralf.gommers＠gmail.com
-
Stefan van der Walt -
Tyler Reddy