More explicit Code of Conduct for the issue tracker & core mailing lists?
Hi folks,
The FreeBSD community recently posted their Code of Conduct guidelines for technical discussions at https://www.freebsd.org/internal/code-of-conduct.html
I think their guidelines align pretty well with the way we try to run the CPython issue tracker and the core mailing lists, but we don't currently spell out those expectations for newcomers (or potential newcomers) as clearly as they have.
Would folks mind if I drafted a CPython Code of Conduct inspired by their example, and proposed it for inclusion in the Developer's Guide?
Regards, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 07/14/2015 07:29 PM, Nick Coghlan wrote:
Would folks mind if I drafted a CPython Code of Conduct inspired by their example, and proposed it for inclusion in the Developer's Guide?
Sounds good to me.
-- ~Ethan~
On Tue, Jul 14, 2015 at 10:29 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
Would folks mind if I drafted a CPython Code of Conduct inspired by their example, and proposed it for inclusion in the Developer's Guide?
The language of the FreeBSD Code of Conduct is a pretty heavy CYA-style corporate legalese, but the overall message sounds right.
+1
On 15 July 2015 at 03:29, Nick Coghlan <ncoghlan@gmail.com> wrote:
Would folks mind if I drafted a CPython Code of Conduct inspired by their example, and proposed it for inclusion in the Developer's Guide?
+1.
I particularly like their point "Try not to take offense where no offense was intended. Not everyone speaks or writes English fluently. Not everyone can express themselves clearly. Give people the benefit of the doubt. Even if the intent was to provoke, do not rise to it." We should aim to be tolerant and forgiving as well as open and inclusive.
Paul
On Jul 15, 2015, at 12:29 PM, Nick Coghlan wrote:
The FreeBSD community recently posted their Code of Conduct guidelines for technical discussions at https://www.freebsd.org/internal/code-of-conduct.html
I wouldn't mind something shorter, perhaps a happy middle ground between that and the PSF CoC? In any case, +1 though...
Would folks mind if I drafted a CPython Code of Conduct inspired by their example, and proposed it for inclusion in the Developer's Guide?
Why not put it in a low-numbered informational PEP?
Cheers, -Barry
I approve of this. I wonder if we can't radically simplify it?
Don't be awful. If someone says 'hey um that makes me uncomfortable' perhaps reconsider what you said. Perhaps say "oh oops, sorry". Don't be an awful person.
Codes of conduct are awesome, but it depresses me that we need to write down rules of basic human decency. On 15 Jul 2015 11:38 pm, "Barry Warsaw" <barry@python.org> wrote:
On Jul 15, 2015, at 12:29 PM, Nick Coghlan wrote:
The FreeBSD community recently posted their Code of Conduct guidelines for technical discussions at https://www.freebsd.org/internal/code-of-conduct.html
I wouldn't mind something shorter, perhaps a happy middle ground between that and the PSF CoC? In any case, +1 though...
Would folks mind if I drafted a CPython Code of Conduct inspired by their example, and proposed it for inclusion in the Developer's Guide?
Why not put it in a low-numbered informational PEP?
Cheers, -Barry
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers
On Wed, Jul 15, 2015 at 6:38 AM Barry Warsaw <barry@python.org> wrote:
On Jul 15, 2015, at 12:29 PM, Nick Coghlan wrote:
The FreeBSD community recently posted their Code of Conduct guidelines for technical discussions at https://www.freebsd.org/internal/code-of-conduct.html
I wouldn't mind something shorter, perhaps a happy middle ground between that and the PSF CoC? In any case, +1 though...
Would folks mind if I drafted a CPython Code of Conduct inspired by their example, and proposed it for inclusion in the Developer's Guide?
Why not put it in a low-numbered informational PEP?
+1 on the idea and on making it a PEP that the devguide can reference since it will essentially be a procedural doc.
Le 15/07/2015 04:29, Nick Coghlan a écrit :
Hi folks,
The FreeBSD community recently posted their Code of Conduct guidelines for technical discussions at https://www.freebsd.org/internal/code-of-conduct.html
This looks good, except that the "In Case of Conflict" part doesn't seem to be really a CoC thing, and their policy there needn't align with ours (although ours would deserve clarifying too).
Regards
Antoine.
On 15.07.2015 04:29, Nick Coghlan wrote:
Hi folks,
The FreeBSD community recently posted their Code of Conduct guidelines for technical discussions at https://www.freebsd.org/internal/code-of-conduct.html
Looks like a good start, but as others have mentioned, I think we ought to simplify this a lot and use it as extension to the CoC we already have rather than as replacement.
I think their guidelines align pretty well with the way we try to run the CPython issue tracker and the core mailing lists, but we don't currently spell out those expectations for newcomers (or potential newcomers) as clearly as they have.
Would folks mind if I drafted a CPython Code of Conduct inspired by their example, and proposed it for inclusion in the Developer's Guide?
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Source
Python Projects, Coaching and Consulting ... http://www.egenix.com/ mxODBC Plone/Zope Database Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::::: Try our mxODBC.Connect Python Database Interface for free ! ::::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
On Wed, Jul 15, 2015 at 12:29:52PM +1000, Nick Coghlan wrote: [...]
I think their guidelines align pretty well with the way we try to run the CPython issue tracker and the core mailing lists, but we don't currently spell out those expectations for newcomers (or potential newcomers) as clearly as they have.
Would folks mind if I drafted a CPython Code of Conduct inspired by their example, and proposed it for inclusion in the Developer's Guide?
Is there an actual social problem you are trying to solve here, or have you just run out of things to do? :-)
The PFS has had a CoC for over a year now. I haven't seen any reduction in "bad behaviour" (it was so low that it would be hard to go any lower), but in my opinion it seems that people are even less inclined to express unpopular viewpoints and more inclined to stay silent. I don't know if that is due to the CoC. I haven't seen anyone directly threated by it for voicing an unpopular opinion, but I know that its at the back of my mind whenever I think about posting. If people don't like what I have to say, can they use the CoC to threaten me? That makes me self-censor all the time, and I don't mean "Am I being a dick?". I mean "How unpopular will this opinion be?"
I spent a *long* time thinking about whether or not I should send this and go against the multitude of +1s, and I'm not sure that people aren't going to hold it against me. (What sort of monster must I be to be against a CoC and in favour of trolls and abuse?) I know of other forums, not Python related, where what I am saying certainly would be held against me for being "disruptive".
To me, a CoC has a definite chilling effect when it comes to voicing opinions that go against the majority. It's hard enough to swim against the tide of popular opinion even in the absense of formal rules that can be used against you. If there was a genuine problem with trolls and abuse on the tracker, then I would consider stronger measures than what we already have in place (i.e. social disapproval, and the ability to close people's account on the tracker). You don't need a CoC to say to somebody "There's no call for that, you went to far, you crossed a line."
-- Steve
Three things. One, I won't hold this view against you, Steven, nor should anyone else. You expressed an opinion politely and it wasn't somehow prejudiced against a group of people. You should never worry about expressing an unpopular opinion as long as it's done with respect and not flat-out evil like being racist or something. The whole point of CoCs is to make it so people feel welcome to express themselves.
Two, the PSF CoC is not retroactively applied to all things. For instance, this list does not fall under the CoC (notice no mention in the footer nor at https://mail.python.org/mailman/listinfo/python-committers). So deciding to apply the PSF CoC to all things related to the development of Python would require something like a PEP.
And three, we need a CoC. Not to explicitly call anyone out, but in the past week or so I have heard peoples' ideas called "ridiculous" and been told to "shut up" on various mailing lists. I have met people at PyCon numerous times who have viewed at least python-dev as at minimum cold and possibly hostile to people, and that's simply not the kind of environment I would like to foster. I honestly think all of us -- including me -- have been way too tolerant of core devs having bad attitudes and not calling them out on it, especially when they simply got too passionate and lost their composure (the magic of email is we can think before we send so tolerating outbursts of any regularity really shouldn't happen). Part of this tolerance for bad attitudes has been cultural, but having a CoC would help to start changing that by making people feel comfortable in standing up and stating they thought someone had been rude.
Anyway, that's why I support having a CoC that applies to everything involving Python's development.
-Brett from a tablet
On Wed, Jul 15, 2015, 21:21 Steven D'Aprano <steve@pearwood.info> wrote:
On Wed, Jul 15, 2015 at 12:29:52PM +1000, Nick Coghlan wrote: [...]
I think their guidelines align pretty well with the way we try to run the CPython issue tracker and the core mailing lists, but we don't currently spell out those expectations for newcomers (or potential newcomers) as clearly as they have.
Would folks mind if I drafted a CPython Code of Conduct inspired by their example, and proposed it for inclusion in the Developer's Guide?
Is there an actual social problem you are trying to solve here, or have you just run out of things to do? :-)
The PFS has had a CoC for over a year now. I haven't seen any reduction in "bad behaviour" (it was so low that it would be hard to go any lower), but in my opinion it seems that people are even less inclined to express unpopular viewpoints and more inclined to stay silent. I don't know if that is due to the CoC. I haven't seen anyone directly threated by it for voicing an unpopular opinion, but I know that its at the back of my mind whenever I think about posting. If people don't like what I have to say, can they use the CoC to threaten me? That makes me self-censor all the time, and I don't mean "Am I being a dick?". I mean "How unpopular will this opinion be?"
I spent a *long* time thinking about whether or not I should send this and go against the multitude of +1s, and I'm not sure that people aren't going to hold it against me. (What sort of monster must I be to be against a CoC and in favour of trolls and abuse?) I know of other forums, not Python related, where what I am saying certainly would be held against me for being "disruptive".
To me, a CoC has a definite chilling effect when it comes to voicing opinions that go against the majority. It's hard enough to swim against the tide of popular opinion even in the absense of formal rules that can be used against you. If there was a genuine problem with trolls and abuse on the tracker, then I would consider stronger measures than what we already have in place (i.e. social disapproval, and the ability to close people's account on the tracker). You don't need a CoC to say to somebody "There's no call for that, you went to far, you crossed a line."
-- Steve
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers
Le 16/07/2015 07:34, Brett Cannon a écrit :
And three, we need a CoC. Not to explicitly call anyone out, but in the past week or so I have heard peoples' ideas called "ridiculous" and been told to "shut up" on various mailing lists.
Which mailing-lists? AFAIK, the CoC would be for python-dev and python-ideas so, if any other MLs are under discussion, it would be good to know.
I have met people at PyCon numerous times who have viewed at least python-dev as at minimum cold and possibly hostile to people,
Each time someone voices such an opinion, it would be nice to get an example from them, and how they feel the welcome should have been like instead. Otherwise it will be hard to make any rational progress. Propagating such opinions could further defeat the purpose (self-reinforcing opinions, or "memes", abound).
Regards
Antoine.
and that's simply not the kind of environment I would like to foster. I honestly think all of us -- including me -- have been way too tolerant of core devs having bad attitudes and not calling them out on it, especially when they simply got too passionate and lost their composure (the magic of email is we can think before we send so tolerating outbursts of any regularity really shouldn't happen). Part of this tolerance for bad attitudes has been cultural, but having a CoC would help to start changing that by making people feel comfortable in standing up and stating they thought someone had been rude.
Anyway, that's why I support having a CoC that applies to everything involving Python's development.
-Brett from a tablet
Le 16/07/2015 07:34, Brett Cannon a écrit :
I have met people at PyCon numerous times who have viewed at least python-dev as at minimum cold and possibly hostile to people, and that's simply not the kind of environment I would like to foster.
For the record, the last time someone said something like that, it was on the PSF-members ML. When it was questioned by several people, I think nobody gave any example or fact to back that opinion.
Regards
Antoine.
On 16 July 2015 at 14:16, Steven D'Aprano <steve@pearwood.info> wrote:
On Wed, Jul 15, 2015 at 12:29:52PM +1000, Nick Coghlan wrote: [...]
I think their guidelines align pretty well with the way we try to run the CPython issue tracker and the core mailing lists, but we don't currently spell out those expectations for newcomers (or potential newcomers) as clearly as they have.
Would folks mind if I drafted a CPython Code of Conduct inspired by their example, and proposed it for inclusion in the Developer's Guide?
Is there an actual social problem you are trying to solve here, or have you just run out of things to do? :-)
There are some practical aspects I'd like to address in a more easily referenced form.
That would primarily be about clarifying ways of handle certain recurring confrontational tasks respectfully:
- redirecting requests for help on either python-dev or python-ideas to Stack Overflow or python-list
- redirecting threads for insufficiently fleshed out suggestions from python-dev to python-ideas
- suggesting that particular ideas may be better suited to a third party package or a personal utility module
- pointing out when an idea has already been considered (and rejected) in the past
- when raising concerns about an already landed change, being clear on the difference between asking for the change to be reverted vs asking for clarification or further improvement
That last one is actually an area where I *dis*agree with the FreeBSD guidelines - I see asking for someone to revert a change as a big deal, as it means we're laying claim to a non-trivial amount of their time. A non-urgent request for clarification is a different story, but I also see us occasionally repeating a pattern where long before the person that actually made a change has a chance to respond to a thread, there'll be half a dozen or more people jumping in saying "Yeah, I want an answer too!".
Given the global nature of the lists, I think we should be giving folks *at least* 24 hours to reply to a question before assuming they're not going to respond, and given that only some of us get to count reading and replying to python-dev threads as work time, a few days leeway would be better (perhaps even a week to account for folks that are busy with other things during the week and mostly contribute on weekends). Those of us that *do* get paid for this also need to try to remember to account for that asymmetry in available time for participation.
The general Python CoC is good as far as it goes, but actually putting openness, respect and kindness into practice on a public international mailing list that now mixes paid contributors with volunteers is a genuinely hard task that could likely benefit from a few pragmatic tips :)
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Thu, Jul 16, 2015 at 10:08 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
That last one is actually an area where I *dis*agree with the FreeBSD guidelines - I see asking for someone to revert a change as a big deal, as it means we're laying claim to a non-trivial amount of their time. A non-urgent request for clarification is a different story, but I also see us occasionally repeating a pattern where long before the person that actually made a change has a chance to respond to a thread, there'll be half a dozen or more people jumping in saying "Yeah, I want an answer too!".
I have seen a couple of these too. Sometimes it is a pile on, but other times it is a very reasonable question to python-dev that goes completely unanswered. Those cases (which are admittedly few) are unfortunate b/c if one person has a question about a commit, then others probably to do. When the question goes unanswered, then we miss out on learning something.
For example, I remember a case from a few months ago where someone (don't remember who off the top of my head) made a micro-optimization and there were post-commit questions about it. As far as I can tell, the question went unanswered and I sincerely was curious what the rationale for the change was. I felt like there was something we all could have learned from the potential discussion around the question that was asked.
Given the global nature of the lists, I think we should be giving folks *at least* 24 hours to reply to a question before assuming they're not going to respond, and given that only some of us get to count reading and replying to python-dev threads as work time, a few days leeway would be better (perhaps even a week to account for folks that are busy with other things during the week and mostly contribute on weekends). Those of us that *do* get paid for this also need to try to remember to account for that asymmetry in available time for participation.
To me this depends on why the change is being questioned. If there is a question about why a change was made or a minor bug was found in post-commit review*, then I agree it can wait a few days. On the other hand, if someone commits a change that turns all the build-bots red and doesn't respond for several hours, then I would think that is fair game to revert.
So, I do think reverting changes is a very reasonable course of action at times. It should just be used judiciously.
-- Meador
- Ideally these kinds of things would be caught in pre-commit review, but I understand that it is not always practical to expect that everyone gets a chance for pre-commit review for every change or that every bug is caught in pre-commit review.
On 17 July 2015 at 01:49, Meador Inge <meadori@gmail.com> wrote:
On Thu, Jul 16, 2015 at 10:08 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
Given the global nature of the lists, I think we should be giving folks *at least* 24 hours to reply to a question before assuming they're not going to respond, and given that only some of us get to count reading and replying to python-dev threads as work time, a few days leeway would be better (perhaps even a week to account for folks that are busy with other things during the week and mostly contribute on weekends). Those of us that *do* get paid for this also need to try to remember to account for that asymmetry in available time for participation.
To me this depends on why the change is being questioned. If there is a question about why a change was made or a minor bug was found in post-commit review*, then I agree it can wait a few days. On the other hand, if someone commits a change that turns all the build-bots red and doesn't respond for several hours, then I would think that is fair game to revert.
So, I do think reverting changes is a very reasonable course of action at times. It should just be used judiciously.
I agree. The problem at the moment is that the norms around various things (particularly relating to pre-commit and post-commit review) are not only largely unwritten but have also changed over time, so we sometimes get mismatched expectations.
Longer term, there are actually some real tooling problems worth fixing (hence the forge.python.org proposals, and the core workflow GSoC projects), but a bit more clarity in our expectations wouldn't hurt in the meantime.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Hi Nick,
Given the amount of ludicrous babble that goes on on python-dev and the like, I've unsubscribed from those lists, so I don't have much interest in this discussion anymore.
I hope you can make them a better place anyway.
Regards
Antoine.
Le 15/07/2015 04:29, Nick Coghlan a écrit :
Hi folks,
The FreeBSD community recently posted their Code of Conduct guidelines for technical discussions at https://www.freebsd.org/internal/code-of-conduct.html
I think their guidelines align pretty well with the way we try to run the CPython issue tracker and the core mailing lists, but we don't currently spell out those expectations for newcomers (or potential newcomers) as clearly as they have.
Would folks mind if I drafted a CPython Code of Conduct inspired by their example, and proposed it for inclusion in the Developer's Guide?
Regards, Nick.
participants (11)
-
Alexander Belopolsky
-
Anthony Baxter
-
Antoine Pitrou
-
Barry Warsaw
-
Brett Cannon
-
Ethan Furman
-
M.-A. Lemburg
-
Meador Inge
-
Nick Coghlan
-
Paul Moore
-
Steven D'Aprano