Making the PSF CoC apply to core developers
I noticed that the devguide didn't explicitly mention that core developers were expected to follow the PSF CoC ( https://docs.python.org/devguide/coredev.html and https://www.python.org/psf/codeofconduct/, respectively). I have opened http://bugs.python.org/issue26446 to make sure it gets documented.
Since this is technically a modification of the requirements of getting commit privileges I wanted to mention it here before I (or anyone else) made the change.
Brett Cannon <brett <at> python.org> writes:
I noticed that the devguide didn't explicitly mention that core developers were expected to follow the PSF CoC (https://docs.python.org/devguide/coredev.html and https://www.python.org/psf/codeofconduct/, respectively). I have opened http://bugs.python.org/issue26446 to make sure it gets documented. Since this is technically a modification of the requirements of getting commit privileges I wanted to mention it here before I (or anyone else) made the change.
When I started here, the PSF and python-dev were considered disjoint entities (quoting MvL from memory). Looking at
https://www.python.org/psf/records/board/history/ ,
half of the current directors have never appeared anywhere on the python-dev infrastructure, most notably on python-checkins.
Contrast this with e.g. the period of 2003-2004, where I still know all of the directors even though I did not know Python at that time!
Some very prolific contributors do not appear in the list of PSF members at all.
This particular CoC specifically addresses conference misbehavior, which is fine. No CoC short of an 800 page volume can address the many forms of human shortcomings in more complex situations. I'm not going to go into detail here, but "suaviter in modo, fortiter in re", even though usually depicted as desirable behavior, can easily lead to more stagnation and friction than occasional superficial impoliteness.
I think python-dev should remain an entity where interested people can just come and "hack on something" instead of being overburdened by regulations.
As for the devguide, briefly mentioning the categorical imperative should suffice. ;)
Stefan Krah
On Sat, 27 Feb 2016 at 04:10 Stefan Krah <stefan@bytereef.org> wrote:
Brett Cannon <brett <at> python.org> writes:
I noticed that the devguide didn't explicitly mention that core developers were expected to follow the PSF CoC (https://docs.python.org/devguide/coredev.html and https://www.python.org/psf/codeofconduct/, respectively). I have opened http://bugs.python.org/issue26446 to make sure it gets documented. Since this is technically a modification of the requirements of getting commit privileges I wanted to mention it here before I (or anyone else) made the change.
When I started here, the PSF and python-dev were considered disjoint entities (quoting MvL from memory). Looking at
https://www.python.org/psf/records/board/history/ ,
half of the current directors have never appeared anywhere on the python-dev infrastructure, most notably on python-checkins.
They are separate organizations. The PSF isn't mandating any of this. After a rather rude email on python-dev I realized we had never clearly stated anywhere that we expect people to be civil on various mailing lists or that we expect all core devs to represent Python by being civil in their interactions with the community.
Contrast this with e.g. the period of 2003-2004, where I still know all of the directors even though I did not know Python at that time!
Some very prolific contributors do not appear in the list of PSF members at all.
This particular CoC specifically addresses conference misbehavior, which is fine. No CoC short of an 800 page volume can address the many forms of human shortcomings in more complex situations. I'm not going to go into detail here, but "suaviter in modo, fortiter in re", even though usually depicted as desirable behavior, can easily lead to more stagnation and friction than occasional superficial impoliteness.
I think python-dev should remain an entity where interested people can just come and "hack on something" instead of being overburdened by regulations.
Python-ideas has been under the same CoC for a while now and it has been nothing but positive. When people know they are expected to behave in a civil manner and others know they are allowed to call someone out for being uncivil it typically is enough to make people behave.
So there is no issue of people "being overburdened by regulations". The CoC only comes up when someone is being so rude that they need to be talked to about their attitude problem, so as long as we try and keep people from being rude it won't come up. Quite frankly, the CoC is really just meant as a way for people to feel comfortable in knowing they don't have to tolerate jerks. And I would hope none of us are jerks to people in the community, so saying as much shouldn't change anything for any of us. This also lets the community know that we don't view ourselves as some elite group of people whose attitudes must be tolerated no matter what; we hold ourselves to the same standards as the rest of the community does and it should be pointed out as such to make people feel comfortable.
As for the devguide, briefly mentioning the categorical imperative should suffice. ;)
As long as we don't require them to actually read Kant, it probably would make a decent CoC. :)
On Sat, Feb 27, 2016 at 05:17:50PM +0000, Brett Cannon wrote:
[...]
After a rather rude email on python-dev
I haven't noticed this email. Care to link to it? We should be allowed to see what sort of behaviour is likely to treated as officially unacceptable in the future.
I think this is actually a very important point. I've seen forums and discussion groups where the enforcement of faux-politeness and "being friendly and positive" and "no jerks allowed" makes the place extremely hostile to anyone who doesn't follow the majority opinion. Where even polite disagreement is seen as "being a jerk". Since rudeness is so subjective, formal prohibitions on being "rude" is a potent weapon for groups to hijack a community by labelling anything and anyone they don't like as "rude". So I think it is important for us to know what you consider is rude enough to require a CoC.
[...]
When people know they are expected to behave in a civil manner and others know they are allowed to call someone out for being uncivil it typically is enough to make people behave.
You don't need a CoC for that. Social expectations apply even without a formal set of rules.
So there is no issue of people "being overburdened by regulations". The CoC only comes up when someone is being so rude that they need to be talked to about their attitude problem,
Who judges that point? Can *anyone* take it upon themselves to (let's say) say "Brett, you unilaterally changed the policy with no discussion or consultation and just four minutes notice. That is unspeakably rude and total jerk behaviour, so under your own rules you're out of here"?
I'm not just making a rhetorical point. I wouldn't accept that sort of unilateral behaviour from my work colleagues. It is pushy and obnoxious and breeds resentment and is exactly the sort of reason why some people are deeply suspicious of CoCs. And when it happens on a Friday night, when people are likely to be away from their computers...
http://politicaldictionary.com/words/friday-news-dump/
My employer learned the hard lesson that even "self-evidently and obviously correct" policy changes need a consultation period before making official. No single manager can be allowed to make unilateral policy changes for the entire group without giving the other relevant managers time to respond. Python is over 20 years old and the core devs have managed without a CoC for all that time. You could have, should have, waited a few days before seemingly ramming this policy change in behind people's backs.
so as long as we try and keep people from being rude it won't come up. Quite frankly, the CoC is really just meant as a way for people to feel comfortable in knowing they don't have to tolerate jerks.
Nobody *has* to tolerate jerks, especially on an email forum. Just filter their emails into the trash.
Or maybe people could be a bit more flexible in what behaviour they accept from others and a bit less quick to label others as jerks?
This is an international group, and I'm an Australian, and the language I use with my wife, friends and co-workers is far more forthright and strong than the language I use here. But if I slip occasionally, and call a spade a bloody shovel as they say, I don't want those with more restrictive, less enlightened or even merely different standards to be able to formally rebuke me. Why should I have to change my behaviour more than I already do? Why can't they be a bit more flexible and accepting of differences and less judgmental?
And I would hope none of us are jerks to people in the community,
If I knew what you considered "a jerk", then I might be able to say whether I agreed or disagreed. For all I know, you might consider this email to be nothing but me being a jerk.
-- Steve
On 28 February 2016 at 12:27, Steven D'Aprano <steve@pearwood.info> wrote:
Nobody *has* to tolerate jerks, especially on an email forum. Just filter their emails into the trash.
This approach means every *future* participant in that community then has to encounter the person that's behaving like a jerk, realise they consistently behave that way, and add them to their own filters. That's grossly disrespectful of everyone's time and energy, include that of the person that's shouting into the wilderness rather than receiving direct and constructive feedback on which aspects of their behaviour are problematic.
Everyone ends up being much better off in the long run if we're explicit about "Don't be a jerk in this environment", rather than pushing the task of putting up with jerkish behaviour back onto individual participants. Things only need to escalate to suspensions and bans if someone proves to be utterly incapable of either moderating their own behaviour or else realising that being involved in Python core development may not be the right activity for them (and I'm personally only aware of one case where we've had to resort to an outright permaban to protect the interests of other volunteers)
Or maybe people could be a bit more flexible in what behaviour they accept from others and a bit less quick to label others as jerks?
This is an international group, and I'm an Australian, and the language I use with my wife, friends and co-workers is far more forthright and strong than the language I use here. But if I slip occasionally, and call a spade a bloody shovel as they say, I don't want those with more restrictive, less enlightened or even merely different standards to be able to formally rebuke me. Why should I have to change my behaviour more than I already do? Why can't they be a bit more flexible and accepting of differences and less judgmental?
This is why *writing things down* instead of just assuming that everybody has a shared understanding of what the phrase "don't be a jerk" means is so important.
And I would hope none of us are jerks to people in the community,
If I knew what you considered "a jerk", then I might be able to say whether I agreed or disagreed. For all I know, you might consider this email to be nothing but me being a jerk.
It doesn't read to me as you being a jerk, but it does read to me as you responding without actually reading the PSF Community Code of Conduct that Brett linked to.
Quoting the document in its entirety:
=============================== The Python community is made up of members from around the globe with a diverse set of skills, personalities, and experiences. It is through these differences that our community experiences great successes and continued growth. When you're working with members of the community, we encourage you to follow these guidelines which help steer our interactions and strive to keep Python a positive, successful, and growing community.
A member of the Python community is:
Open
Members of the community are open to collaboration, whether it's on PEPs, patches, problems, or otherwise. We're receptive to constructive comment and criticism, as the experiences and skill sets of other members contribute to the whole of our efforts. We're accepting of all who wish to take part in our activities, fostering an environment where anyone can participate and everyone can make a difference.
Considerate
Members of the community are considerate of their peers -- other Python users. We're thoughtful when addressing the efforts of others, keeping in mind that often times the labor was completed simply for the good of the community. We're attentive in our communications, whether in person or online, and we're tactful when approaching differing views.
Respectful
Members of the community are respectful. We're respectful of others, their positions, their skills, their commitments, and their efforts. We're respectful of the volunteer efforts that permeate the Python community. We're respectful of the processes set forth in the community, and we work within them. When we disagree, we are courteous in raising our issues.
Overall, we're good to each other. We contribute to this community not because we have to, but because we want to. If we remember that, these guidelines will come naturally.
For mailing lists, the enforcement procedures are the same as those that have existed on all mailing lists since time immemorial: the list moderators have full authority to impose forced moderation and outright bans on folks that they consider to be interfering with the list's ability to achieve its intended purpose.
There's a *different* document, which I assume is the one Stefan is referring to given his mention of conferences, which is the one used to define acceptable behaviour at PyCon US: https://us.pycon.org/2015/about/code-of-conduct/
Again, that is about putting behavioural expectations in writing since we *can't* assume a shared understanding of phrases like "don't be a jerk" and "don't harass people" when attendees are flying in from all over the world.
Regards, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Sun, Feb 28, 2016 at 03:11:25PM +1000, Nick Coghlan wrote:
On 28 February 2016 at 12:27, Steven D'Aprano <steve@pearwood.info> wrote:
Nobody *has* to tolerate jerks, especially on an email forum. Just filter their emails into the trash.
This approach means every *future* participant in that community then has to encounter the person that's behaving like a jerk, realise they consistently behave that way, and add them to their own filters. [...]
It also means they get to decide for themselves what is and isn't unacceptable behaviour *to them*, without imposing those values on those who don't share them.
Look, I get it. I'm outvoted, and the community -- at least those who are willing to speak up publicly -- agree with the CoC. I'm obviously in a minority here, and I accept that.
But that's not the point. The point is that if we're actually going to be "open, respectful and considerate" as the CoC requires, then we actually have to make time to listen to those diverse viewpoints we say we want to listen to. If we're serious about the CoC, then we should treat it seriously and not just give lip-service to it.
How can we say we're in favour of diversity if we don't give those diverse voices and viewpoints a chance to speak up before making decisions? Community values come from the entire community, not just from a couple of guys with admin powers on the mailing list software.
Being open, respectful and considerate means that, even if you have the de facto power to apply whatever rules you want, you *ask first* and listen to what the community has to say. Maybe you'll be surprised by what they say. Maybe you won't. But you won't know unless you ask.
Even if the community is overwhelmingly in favour of the change, at least those with a different opinion will have had the chance to be heard. And that is critical for a healthy community. "You never listen" is deadly for relationships, whether they are family, business or community. There is a reason why members of minorities are often described as "voiceless", and why we should *listen to them*.
Even if, after due consideration, we choose to dismiss their point of view. We're all adults here, and I trust that none of us expect to "win" all the time. So long as we get a fair chance to have our say and have it honestly considered with an open mind. I don't ask for anything more than that.
The most frustrating thing is that we've been through this before. In 2013, Brett and Titus did exactly the same thing on the Python-Ideas list:
https://mail.python.org/pipermail/python-ideas/2013-June/021087.html
So let me make it clear: Brett, and the other list maintainers, you're not listening. Even if I'm a minority of one out of the whole community, your words say "of course we care what you think" but your actions say "actually no, we couldn't care less". You might not have intended it that way, but nevertheless that's the way it is.
Imagine an alternate universe where Brett had said, "I'm the dictator of this mailing list and I don't care what anyone thinks. From now on, I'm going to ban 'jerk' behaviour, and if you don't like it, tough." How exactly is that alternate universe different from what actually took place?
When this happened on Python-Ideas, people wrote to me defending the change on exactly that basis: Brett's the dictator and can do what he likes, he doesn't have to listen, if I don't like it, I should leave. This was coming from people who were vigourously supporting the CoC and the need to be welcoming to all. If there is a way to reconcile those two seemingly contradictory positions, I don't know what it is.
I'm not accusing Brett or anyone else of being a moustache-twirling villain who is out to ruin this group, or of acting maliciously. I truly believe that he is trying to act in the best interests of the community. But I think he is failing. It takes actual effort to listen to minority views, really listen, not just say "we're listening", and in this case I feel that Brett didn't even bother with the "we're listening" part, he just went straight to the "we know what's best".
Having your voice heard goes a long way to making people feel welcome. Having rules applied by fiat with no opportunity to be heard is not open, respectful or considerate, but it is a good way to build resentment and make people feel like outsiders. Which is exactly how I feel now.
(Although the measured and reasonable responses to my earlier email have gone a long way towards mitigating that. Thank you to all those who replied respectfully, and thankfully this time I wasn't told to GTFO if I didn't like it.)
I have worked in a team where managers would apply policy changes that affected the entire team (including other managers) without a period of consultation, and it is toxic behaviour. It breeds resentment and a feeling of being pushed into the outer. The feeling of voicelessness can break work-places, families and entire communities, and one of the most important parts of social justice is to give people a voice.
Technically, the CoC only says that we should be "receptive to constructive comment and criticism", it doesn't say anything about avoiding criticism in the first place by consulting with the community before making changes that affects them. But I think that the three overriding principles of openness, respect and consideration should apply *proactively*, not just retroactively.
If I knew what you considered "a jerk", then I might be able to say whether I agreed or disagreed. For all I know, you might consider this email to be nothing but me being a jerk.
It doesn't read to me as you being a jerk, but it does read to me as you responding without actually reading the PSF Community Code of Conduct that Brett linked to.
Nick, give me some credit. I was around when the PSF voted on this the first time, and I was around when it was applied to the Python-Ideas list. I've read the CoC many times, and I'm quite familiar with it. This is not some knee-jerk reaction. I've been thinking about this issue for some time.
-- Steve
On 02/29/2016 06:00 PM, Steven D'Aprano wrote:
I have worked in a team where managers would apply policy changes that affected the entire team (including other managers) without a period of consultation, and it is toxic behaviour. It breeds resentment and a feeling of being pushed into the outer. The feeling of voicelessness can break work-places, families and entire communities, and one of the most important parts of social justice is to give people a voice.
Very true. Thank you for speaking up and being persistent.
-- ~Ethan~
On Mon, 29 Feb 2016 at 18:01 Steven D'Aprano <steve@pearwood.info> wrote:
On Sun, Feb 28, 2016 at 03:11:25PM +1000, Nick Coghlan wrote:
On 28 February 2016 at 12:27, Steven D'Aprano <steve@pearwood.info> wrote:
Nobody *has* to tolerate jerks, especially on an email forum. Just filter their emails into the trash.
This approach means every *future* participant in that community then has to encounter the person that's behaving like a jerk, realise they consistently behave that way, and add them to their own filters. [...]
It also means they get to decide for themselves what is and isn't unacceptable behaviour *to them*, without imposing those values on those who don't share them.
Look, I get it. I'm outvoted, and the community -- at least those who are willing to speak up publicly -- agree with the CoC. I'm obviously in a minority here, and I accept that.
But that's not the point. The point is that if we're actually going to be "open, respectful and considerate" as the CoC requires, then we actually have to make time to listen to those diverse viewpoints we say we want to listen to. If we're serious about the CoC, then we should treat it seriously and not just give lip-service to it.
How can we say we're in favour of diversity if we don't give those diverse voices and viewpoints a chance to speak up before making decisions? Community values come from the entire community, not just from a couple of guys with admin powers on the mailing list software.
Being open, respectful and considerate means that, even if you have the de facto power to apply whatever rules you want, you *ask first* and listen to what the community has to say. Maybe you'll be surprised by what they say. Maybe you won't. But you won't know unless you ask.
Even if the community is overwhelmingly in favour of the change, at least those with a different opinion will have had the chance to be heard. And that is critical for a healthy community. "You never listen" is deadly for relationships, whether they are family, business or community. There is a reason why members of minorities are often described as "voiceless", and why we should *listen to them*.
Even if, after due consideration, we choose to dismiss their point of view. We're all adults here, and I trust that none of us expect to "win" all the time. So long as we get a fair chance to have our say and have it honestly considered with an open mind. I don't ask for anything more than that.
The most frustrating thing is that we've been through this before. In 2013, Brett and Titus did exactly the same thing on the Python-Ideas list:
https://mail.python.org/pipermail/python-ideas/2013-June/021087.html
So let me make it clear: Brett, and the other list maintainers, you're not listening. Even if I'm a minority of one out of the whole community, your words say "of course we care what you think" but your actions say "actually no, we couldn't care less". You might not have intended it that way, but nevertheless that's the way it is.
I see where the issue came in: I simply considered the discussion on the CoC already settled. As you pointed out in your second paragraph, the community has decided that they like the idea of a CoC (for instance, I was applauded at PyCon US 2014 when I gave the opening address and pointed out that there was a CoC in effect). I also went through these points with python-ideas years ago (and you're right, it wasn't a discussion as much as an edict of new rules on python-ideas, but I felt that was necessary to deal with the situation). I wasn't trying to silence dissent, I just considered it a settled point.
And the key word for me is "settled". It's like people wanting a Python 2.8 release: at some point we decided the key points were made and that our decision had been settled. I feel the same way about the CoC, so I didn't view it as silencing the anti-CoC side before they could argue as much as the argument had been had and the CoC side had won.
Imagine an alternate universe where Brett had said, "I'm the dictator of this mailing list and I don't care what anyone thinks. From now on, I'm going to ban 'jerk' behaviour, and if you don't like it, tough." How exactly is that alternate universe different from what actually took place?
Two ways. One, the CoC is at least written down so it isn't quite so arbitrary as "Brett says so!" The other is that I considered it "... tough, because we have already had this discussion as a community and decided having a CoC is a good thing".
When this happened on Python-Ideas, people wrote to me defending the change on exactly that basis: Brett's the dictator and can do what he likes, he doesn't have to listen, if I don't like it, I should leave. This was coming from people who were vigourously supporting the CoC and the need to be welcoming to all. If there is a way to reconcile those two seemingly contradictory positions, I don't know what it is.
In that instance I think it's because when you come down on the anti-CoC side, the pro side tend to view it as you're putting the worry of silencing dissenting voices over protecting those who feel they can't speak up without a CoC. And since the pro side views the CoC as enough to prevent dissenting voices from being silenced in the first place then that makes the anti-CoC as censoring more implicitly and the possible explicit censoring of the anti- side.
I'm not accusing Brett or anyone else of being a moustache-twirling villain who is out to ruin this group, or of acting maliciously. I truly believe that he is trying to act in the best interests of the community. But I think he is failing. It takes actual effort to listen to minority views, really listen, not just say "we're listening", and in this case I feel that Brett didn't even bother with the "we're listening" part, he just went straight to the "we know what's best".
Having your voice heard goes a long way to making people feel welcome. Having rules applied by fiat with no opportunity to be heard is not open, respectful or considerate, but it is a good way to build resentment and make people feel like outsiders. Which is exactly how I feel now.
(Although the measured and reasonable responses to my earlier email have gone a long way towards mitigating that. Thank you to all those who replied respectfully, and thankfully this time I wasn't told to GTFO if I didn't like it.)
I have worked in a team where managers would apply policy changes that affected the entire team (including other managers) without a period of consultation, and it is toxic behaviour. It breeds resentment and a feeling of being pushed into the outer. The feeling of voicelessness can break work-places, families and entire communities, and one of the most important parts of social justice is to give people a voice.
Right, but as I said earlier in this email, this was not some knee-jerk decision where opposing voices had not been listened to previously. To me the CoC debate spanned years and has been settled at this point. So it isn't like a manager walking into a meeting and saying "we're switching to Java because I say so", it's more like "the rest of the company has standardized on Python and we're the lone hold-outs, so we're finally going to align with the rest of the company".
-Brett
On Tue, 01 Mar 2016 04:10:08 +0000, Brett Cannon <brett@python.org> wrote:
On Mon, 29 Feb 2016 at 18:01 Steven D'Aprano <steve@pearwood.info> wrote:
So let me make it clear: Brett, and the other list maintainers, you're not listening. Even if I'm a minority of one out of the whole community, your words say "of course we care what you think" but your actions say "actually no, we couldn't care less". You might not have intended it that way, but nevertheless that's the way it is.
I see where the issue came in: I simply considered the discussion on the CoC already settled. As you pointed out in your second paragraph, the
Just so Steven doesn't think he's a minority of one, let me say that I too find CoCs problematic. I have a code of conduct, and it applies to my *life*. For shorthand, you could call it "being a gentleman", but a more modern term might be "being civil". Do I fail to live up to my personal code occasionally? Yes, and I hope people call me on it when I do fail. Do I care what code of conduct the organization has promulgated? No. It has no affect on my behavior, nor will it. At most, it might drive me from the community if it is ever used against me.
Referencing a CoC will only work at all with those who are self-governed by a personal code of civility. Yet all such people need is to have it pointed out to them that they have been uncivil, with reference to the universal code of civility and/or a civil discussion about civility in the immediate context.
Those who are not already self-governed by a personal code of civility will not be bound by the CoC, though they may give it lip service and carry on a long, probably uncivil, argument about the rules embodied in the CoC.
Against those who are not self-governed, only power plays, which ultimately probably means expulsion by technical means, will work...and what matters it if you reference that expulsion to a specific code of conduct, or the universal one?
How it actually matters is that people who are not civil will "rules lawyer" you on the specific one if you have one and you attempt to use it to police their behavior. Worse, they will use it to "rules lawyer" people they don't like or whose opinions they object to.
When things get bad enough that a call to (universal) civility is not enough, ultimately someone has to make the call. That person might as well do it based on their own moral code, as the "owner" of the resource[*], and not have to try to justify it based on some specific set of rules-on-paper. They are going to take flak for making the decision anyway, so why hand the uncivil an extra weapon?
Note that I am not saying that there aren't/weren't problems. Those problems need to be (and are) addressed *universally* by a change in civic culture via the cultural dialog that is always going on around us. Discussions of what civility is in the context of specific incidents are an important part of that. Specific codes of conduct, on the other hand, very often make the problem *worse*, and delay the implementation of beneficial cultural shifts, because they attempt to freeze the rules, very often do it badly, and thus become instead a weapon in the hands of the uncivil and/or the power hungry.
All that said, the Python CoC is not a bad restatement of parts of the universal code, so it is hopefully less subject to this abuse than others that I have seen. For that I am thankful. As I am thankful that the Python community rarely has conflicts that rise to the level of intransigent uncivility. The fundamental civility of this community is one of the things that I value about it, even if it isn't quite perfect :)
--David
[*] Yes, in our case that is ultimately Guido, as Brett indicated.
On 1 March 2016 at 17:36, R. David Murray <rdmurray@bitdance.com> wrote:
On Tue, 01 Mar 2016 04:10:08 +0000, Brett Cannon <brett@python.org> wrote:
On Mon, 29 Feb 2016 at 18:01 Steven D'Aprano <steve@pearwood.info> wrote:
So let me make it clear: Brett, and the other list maintainers, you're not listening. Even if I'm a minority of one out of the whole community, your words say "of course we care what you think" but your actions say "actually no, we couldn't care less". You might not have intended it that way, but nevertheless that's the way it is.
I see where the issue came in: I simply considered the discussion on the CoC already settled. As you pointed out in your second paragraph, the
Just so Steven doesn't think he's a minority of one, let me say that I too find CoCs problematic. I have a code of conduct, and it applies to my *life*. For shorthand, you could call it "being a gentleman", but a more modern term might be "being civil". Do I fail to live up to my personal code occasionally? Yes, and I hope people call me on it when I do fail. Do I care what code of conduct the organization has promulgated? No. It has no affect on my behavior, nor will it. At most, it might drive me from the community if it is ever used against me.
Let me also add that I have little or no interest in codes of conduct. I don't *object* to them (specifically I have no problem with the Python CoC or it being applied to core devs in relevant situations) but it seems to me that they are becoming a bit of a "trendy thing to have" rather than anything of any particular substance.
But ultimately what matters is that people who feel unwelcome, or discriminated against, have said that they help lessen such problems - so that's fine by me. I'm 100% behind doing whatever makes such people feel better about participating in the community.
Contrariwise, I wouldn't feel any need to refer to a CoC when calling someone out on bad behaviour - if pointing out that they are being unpleasant isn't enough then waving a set of rules at them won't help. And if *I* ever behave badly, I'd expect people to simply say so, not to quote a CoC at me.
Going into specifics:
Brett - I don't have any problem with what you did, or the changes you want to make. Steven - you make some good points that I think people should keep in mind But overall, arguing over the specifics of how we set our expectations that people simply be nice to each other is basically a bit silly, and if we let it go on, could easily result in the opposite effect from what was intended.
That's about all I have to say on this matter. Paul
On Tue, Mar 1, 2016 at 12:36 PM, R. David Murray <rdmurray@bitdance.com> wrote:
On Tue, 01 Mar 2016 04:10:08 +0000, Brett Cannon <brett@python.org> wrote:
On Mon, 29 Feb 2016 at 18:01 Steven D'Aprano <steve@pearwood.info>
wrote:
So let me make it clear: Brett, and the other list maintainers, you're not listening. Even if I'm a minority of one out of the whole community, your words say "of course we care what you think" but your actions say "actually no, we couldn't care less". You might not have intended it that way, but nevertheless that's the way it is.
I see where the issue came in: I simply considered the discussion on the CoC already settled. As you pointed out in your second paragraph, the
Just so Steven doesn't think he's a minority of one, let me say that I too find CoCs problematic.
I did not think I would ever reply in this thread, but its 25+ messages in my inbox made me click on the CoC link and actually read it.
As a result, I am truly puzzled. The CoC just states "we're good to each other" in not so many words. The dispute over Brett not being good to others by stating that we all are reminds me of the Russell's paradox. [1]
I suggest that we deal with the question "Does CoC apply to core developers?" in the same manner the modern set theory deals with the Barber problem.
On Tue, 1 Mar 2016 at 09:36 R. David Murray <rdmurray@bitdance.com> wrote:
On Tue, 01 Mar 2016 04:10:08 +0000, Brett Cannon <brett@python.org> wrote:
On Mon, 29 Feb 2016 at 18:01 Steven D'Aprano <steve@pearwood.info> wrote:
So let me make it clear: Brett, and the other list maintainers, you're not listening. Even if I'm a minority of one out of the whole community, your words say "of course we care what you think" but your actions say "actually no, we couldn't care less". You might not have intended it that way, but nevertheless that's the way it is.
I see where the issue came in: I simply considered the discussion on the CoC already settled. As you pointed out in your second paragraph, the
Just so Steven doesn't think he's a minority of one, let me say that I too find CoCs problematic. I have a code of conduct, and it applies to my *life*. For shorthand, you could call it "being a gentleman", but a more modern term might be "being civil". Do I fail to live up to my personal code occasionally? Yes, and I hope people call me on it when I do fail. Do I care what code of conduct the organization has promulgated? No. It has no affect on my behavior, nor will it. At most, it might drive me from the community if it is ever used against me.
Referencing a CoC will only work at all with those who are self-governed by a personal code of civility. Yet all such people need is to have it pointed out to them that they have been uncivil, with reference to the universal code of civility and/or a civil discussion about civility in the immediate context.
I don't want this discussion to drag on forever as CoC discussions tend to, but I do want to point out that the CoC serves two purposes: putting in writing that people are expected to behave appropriately instead of purely by unspoken social contract and thus have something to point to when dealing with bad actors, and to make people who feel like a minority to know that someone who is in the majority cannot bully or out-shout them without consequences.
It's that last point I really care about with this group (in the case of python-ideas it was the former). If you look at our makeup, we are all men and of the dominant ethnic group in our home country (if I'm wrong, please let me know). I suspect the vast majority of us have never experienced systemic discrimination for extended periods of time (I'm talking for months, not while on vacation for a week or two). And if you didn't know coming into python-dev, the issue tracker, or GitHub that bad behaviour won't be tolerated, it can be quite a barrier to entry as it's very easy to want to avoid participation if you don't have a spirit for fighting when you think you may have to fight to participate.
For instance, I actually did experience discrimination in high school in the US while on a sports team. I happened to be one of two white kids on the team and it was made abundantly clear by our teammates that we were the ethnic minority. It sucked and it very quickly makes you try and avoid confrontations because you know you may be outnumbered if you ask people to stop verbally abusing you and the majority choose not to comply. And this extends to going to greater powers when you don't know if they will take your side on verbal abuse since if they don't you will be outnumbered by the majority and thus have little in the way or protection against potential retaliation over trying to get help (luckily when we did go to our coach, while he didn't believe us in terms of severity, people basically got the point and things improved, but there was always an undercurrent of being different to the point the other kid quit the team, making me a minority of one). Being a minority really sucks when you don't know if the majority will support you when you have to fight to be treated fairly and with kindness.
And that's what I want for us. I want people to know that they can participate here and know we will do it in a civil manner and that even if you are technically a minority compared to the group in the real world, you will be treated as an equal. Whether the CoC really ever has to be used or how much teeth it may have is not entirely the point: it's about how outsiders feel and if they feel protected and comfortable. It's letting others know that if they come here and happen to be treated badly -- even if I doubt that will truly ever happen from a core dev -- that they won't have to fight to continue to participate or simply walk away because of how they were treated by someone. The simple act of writing it down can mean a lot to know that we at least strive for that. In this instance (written) words speak louder than actions when you don't know what the dynamic of a group is ahead of time. The participation of women at PyCon US thanks to a combination of a CoC and outreach is proof this stuff can make a difference in participation.
Now obviously I could be totally wrong and this isn't an actual barrier for getting women or ethnic minorities to participate in Python's development. But from my perspective, the chances that the lack of CoC is causing someone to not participate seems greater than the chances that the CoC will somehow be abused to silence someone who has a valid point that was delivered in a reasonable tone. And this is why I'm working to get everything we do as core devs under the PSF CoC (which I have said previously is python-dev, bugs.python.org, and GitHub at this point).
On Tue, 01 Mar 2016 19:00:21 +0000, Brett Cannon <brett@python.org> wrote:
I don't want this discussion to drag on forever as CoC discussions tend to,
Agreed, I made my point and don't otherwise feel a need to engage in further discussion. Unless someone pushes one of my buttons, I suppose :)
Now obviously I could be totally wrong and this isn't an actual barrier for getting women or ethnic minorities to participate in Python's development.
Yeah, there's no way to know, as far as I can see. But I think our *being* welcoming is way, *way* more important than our *saying* we are welcoming.
--David
On 2 March 2016 at 05:44, R. David Murray <rdmurray@bitdance.com> wrote:
On Tue, 01 Mar 2016 19:00:21 +0000, Brett Cannon <brett@python.org> wrote:
Now obviously I could be totally wrong and this isn't an actual barrier for getting women or ethnic minorities to participate in Python's development.
Yeah, there's no way to know, as far as I can see. But I think our *being* welcoming is way, *way* more important than our *saying* we are welcoming.
Words that weren't backed up by behaviour would be false advertising, and hence far more problematic than silence or an explicit statement that an environment is deliberately adversarial.
However, it also isn't reasonable for open source projects to expect potential contributors to invest weeks or months in assessing their likely treatment if they speak up on a mailing list or submit a new patch - it turns out that having the kind of spare time needed to speculatively invest in following a community for long enough to make that kind of judgement for ourselves is a rare luxury.
That's where written behavioural commitments can help - as long as they accurately reflect the way that community members actually strive to conduct themselves, than it helps newcomers better assess "Am I likely to feel comfortable here?".
Regards, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Sat, 27 Feb 2016 at 18:33 Steven D'Aprano <steve@pearwood.info> wrote:
On Sat, Feb 27, 2016 at 05:17:50PM +0000, Brett Cannon wrote:
[...]
After a rather rude email on python-dev
I haven't noticed this email. Care to link to it? We should be allowed to see what sort of behaviour is likely to treated as officially unacceptable in the future.
https://mail.python.org/pipermail/python-dev/2016-February/143417.html is the key email (there were two before it where tensions started to rise; you can see my public response later in that thread.
I think this is actually a very important point. I've seen forums and discussion groups where the enforcement of faux-politeness and "being friendly and positive" and "no jerks allowed" makes the place extremely hostile to anyone who doesn't follow the majority opinion.
I have never seen this happen in the Python community.
Where even polite disagreement is seen as "being a jerk".
That would go against the very first part of the PSF CoC about being open.
Since rudeness is so subjective, formal prohibitions on being "rude" is a potent weapon for groups to hijack a community by labelling anything and anyone they don't like as "rude". So I think it is important for us to know what you consider is rude enough to require a CoC.
[...]
When people know they are expected to behave in a civil manner and others know they are allowed to call someone out for being uncivil it typically is enough to make people behave.
You don't need a CoC for that. Social expectations apply even without a formal set of rules.
That is not the experience I've had on python-ideas. Since I implemented the CoC over there I think the discourse has cleaned up a good amount.
So there is no issue of people "being overburdened by regulations". The CoC only comes up when someone is being so rude that they need to be talked to about their attitude problem,
Who judges that point?
Just like any other point discussed here; either we reach consensus as a group or Guido makes a final call.
Can *anyone* take it upon themselves to (let's say) say "Brett, you unilaterally changed the policy with no discussion or consultation and just four minutes notice. That is unspeakably rude and total jerk behaviour, so under your own rules you're out of here"?
I'm not just making a rhetorical point. I wouldn't accept that sort of unilateral behaviour from my work colleagues.
It wasn't a unilateral decision. If it was then I would have just done it without opening an issue or bringing it up here. I mentioned it here just in case someone might get upset by it (which obviously happened).
It is pushy and obnoxious and breeds resentment and is exactly the sort of reason why some people are deeply suspicious of CoCs. And when it happens on a Friday night, when people are likely to be away from their computers...
It happened Friday night because that's when I read the email on python-dev that triggered me to go through all the mailing lists I manage and make sure they mention the PSF CoC applies there. There was no purposeful trick to try and sneak this through (if I was trying to sneak it in then I did a bad job by bringing this up here and/or not just committing the update immediately). I'm not sure how you manage your Python contribution time, but for me I don't have as much as I like and so I seize on it when I can and I don't pay attention to what day of the week it is.
My employer learned the hard lesson that even "self-evidently and obviously correct" policy changes need a consultation period before making official. No single manager can be allowed to make unilateral policy changes for the entire group without giving the other relevant managers time to respond. Python is over 20 years old and the core devs have managed without a CoC for all that time.
I'm quite aware of that having been a core dev for 13 of those years. But that doesn't mean we can't improve the situation. And this is more about giving people outside of the core dev group piece of mind than it is about explicitly worrying about a core dev violating the CoC. I do not want people thinking we are above reproach, and so I thought it would be good to publicly state that we are not and we hold ourselves to the same standards we expect everyone to follow at every major Python conference, on mailing lists, etc. when it involves us representing Python and the other core devs on this list.
You could have, should have, waited a few days before seemingly ramming this policy change in behind people's backs.
Steven, I didn't try to sneak this past anyone. I honestly didn't expect it to be that controversial at this point which is why the email is almost nonchalant in saying that I viewed posting here as a technicality. I seriously thought we as a community were passed CoCs being controversial based on the resounding acceptance at Python conferences and my positive experience on various mailing lists like python-ideas.
so as long as we try and keep people from being rude it won't come up. Quite frankly, the CoC is really just meant as a way for people to feel comfortable in knowing they don't have to tolerate jerks.
Nobody *has* to tolerate jerks, especially on an email forum. Just filter their emails into the trash.
Nick already addressed this comment the exact way I would have.
Or maybe people could be a bit more flexible in what behaviour they accept from others and a bit less quick to label others as jerks?
Nick replied to this the way I would have as well.
This is an international group, and I'm an Australian, and the language I use with my wife, friends and co-workers is far more forthright and strong than the language I use here. But if I slip occasionally, and call a spade a bloody shovel as they say, I don't want those with more restrictive, less enlightened or even merely different standards to be able to formally rebuke me. Why should I have to change my behaviour more than I already do? Why can't they be a bit more flexible and accepting of differences and less judgmental?
There is a massive difference between using a word that someone might consider a swear word and regularly being mean or disrespectful.
And I would hope none of us are jerks to people in the community,
If I knew what you considered "a jerk", then I might be able to say whether I agreed or disagreed. For all I know, you might consider this email to be nothing but me being a jerk.
I think the tone was a bit much here and there, but I know it's not to be mean and it stems from a passion on this topic (although I have to admit the accusations that I tried to sneak this passed everyone through some devious scheme did hurt a bit).
I swear that I did not mean to pull a fast one or somehow exert some influence to make this happen on the sly and I'm sorry if you thought that; I seriously thought it wasn't going to be an issue. But since it is for some I promise I won't make any change to the devguide unless clear consensus can be reached or Guido tells me to flat-out (just like any other change that affects Python).
On 02/28/2016 08:10 PM, Brett Cannon wrote:
Can *anyone* take it upon themselves to (let's say) say "Brett, you unilaterally changed the policy with no discussion or consultation and just four minutes notice. That is unspeakably rude and total jerk behaviour, so under your own rules you're out of here"? I'm not just making a rhetorical point. I wouldn't accept that sort of unilateral behaviour from my work colleagues.It wasn't a unilateral decision. If it was then I would have just done it without opening an issue or bringing it up here. I mentioned it here just in case someone might get upset by it (which obviously happened).
FWIW, Eric Smith and myself (co-"owners" of the mailing list) supported this when Brett asked.
I hope, Steven, you're by now convinced that this wasn't a cloak-and-dagger operation (really, for volunteer work there is no such thing as "business hours").
Neither is it a unique thing for a python.org mailing list. This is especially important: what is so different about python-ideas that it needs the CoC, while -committers doesn't? Much better to be consistent and to have the same standards applied to every list (eventually).
cheers, Georg
On Sun, Feb 28, 2016, 12:02 Georg Brandl <g.brandl@gmx.net> wrote:
On 02/28/2016 08:10 PM, Brett Cannon wrote:
Can *anyone* take it upon themselves to (let's say) say "Brett, you unilaterally changed the policy with nodiscussion
or consultation and just four minutes notice. That is unspeakablyrude
and total jerk behaviour, so under your own rules you're out ofhere"?
I'm not just making a rhetorical point. I wouldn't accept that sortof
unilateral behaviour from my work colleagues.It wasn't a unilateral decision. If it was then I would have just done it without opening an issue or bringing it up here. I mentioned it here
just in
case someone might get upset by it (which obviously happened).
FWIW, Eric Smith and myself (co-"owners" of the mailing list) supported this when Brett asked.
I think Steven's objection was me wanting to state in the devguide that core devs would adhere to the CoC in all Python-related interactions in the community regardless of whether that interaction explicitly occurred under the purview of the CoC, which is a stronger statement than just this mailing list being under the CoC.
-Brett
I hope, Steven, you're by now convinced that this wasn't a cloak-and-dagger operation (really, for volunteer work there is no such thing as "business hours").
Neither is it a unique thing for a python.org mailing list. This is especially important: what is so different about python-ideas that it needs the CoC, while -committers doesn't? Much better to be consistent and to have the same standards applied to every list (eventually).
cheers, Georg
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
On 02/28/2016 10:25 PM, Brett Cannon wrote:
On Sun, Feb 28, 2016, 12:02 Georg Brandl <g.brandl@gmx.net <mailto:g.brandl@gmx.net>> wrote:
On 02/28/2016 08:10 PM, Brett Cannon wrote: > Can *anyone* take it upon themselves to (let's > say) say "Brett, you unilaterally changed the policy with no discussion > or consultation and just four minutes notice. That is unspeakably rude > and total jerk behaviour, so under your own rules you're out of here"? > > I'm not just making a rhetorical point. I wouldn't accept that sort of > unilateral behaviour from my work colleagues. > > > It wasn't a unilateral decision. If it was then I would have just done it > without opening an issue or bringing it up here. I mentioned it here just in > case someone might get upset by it (which obviously happened). FWIW, Eric Smith and myself (co-"owners" of the mailing list) supported this when Brett asked.I think Steven's objection was me wanting to state in the devguide that core devs would adhere to the CoC in all Python-related interactions in the community regardless of whether that interaction explicitly occurred under the purview of the CoC, which is a stronger statement than just this mailing list being under the CoC.
Well, "Python-related" is a bit strong and includes activities the PSF/the CPython developer community has no business in. It should be rephrased to "Python core-related" - that mostly happens through the mailing lists (and the tracker). We should not presume to be an employer that will fire employees based on a post on their private Facebook account.
cheers, Georg
On Sun, 28 Feb 2016 at 23:15 Georg Brandl <g.brandl@gmx.net> wrote:
On 02/28/2016 10:25 PM, Brett Cannon wrote:
On Sun, Feb 28, 2016, 12:02 Georg Brandl <g.brandl@gmx.net <mailto:g.brandl@gmx.net>> wrote:
On 02/28/2016 08:10 PM, Brett Cannon wrote: > Can *anyone* take it upon themselves to (let's > say) say "Brett, you unilaterally changed the policy with nodiscussion
> or consultation and just four minutes notice. That isunspeakably rude
> and total jerk behaviour, so under your own rules you're outof here"?
> > I'm not just making a rhetorical point. I wouldn't accept thatsort of
> unilateral behaviour from my work colleagues. > > > It wasn't a unilateral decision. If it was then I would have justdone it
> without opening an issue or bringing it up here. I mentioned ithere just in
> case someone might get upset by it (which obviously happened). FWIW, Eric Smith and myself (co-"owners" of the mailing list)supported this
when Brett asked.I think Steven's objection was me wanting to state in the devguide that
devs would adhere to the CoC in all Python-related interactions in the community regardless of whether that interaction explicitly occurred under the
core purview of
the CoC, which is a stronger statement than just this mailing list being under the CoC.
Well, "Python-related" is a bit strong and includes activities the PSF/the CPython developer community has no business in. It should be rephrased to "Python core-related" - that mostly happens through the mailing lists (and the tracker). We should not presume to be an employer that will fire employees based on a post on their private Facebook account.
That rephrasing is fine by me (as would be adding "public" to the statement). My point is when any of us have our core-dev "hat" on, people should know that they can expect us to behave appropriately and that if we misstep and say something offensive they can point it out to us without worries of any of us taking offense (i.e., we are just like everyone else and being a core dev doesn't place our behaviour above anyone else). If we happen to be at a meetup or conference that has not implemented a CoC that shouldn't give us an excuse as esteemed representatives of this language and community to be lax in our behaviour since how we act as core devs is probably amplified compared to others in the community.
On 29.02.2016 18:38, Brett Cannon wrote:
... If we happen to be at a meetup or conference that has not implemented a CoC that shouldn't give us an excuse as esteemed representatives of this language and community to be lax in our behaviour since how we act as core devs is probably amplified compared to others in the community.
This is the part about all this CoC talk I never understand. Why on earth would someone change their regular behavior when "at a meetup or conference that has not implemented a CoC" ?
This sounds to me like a very "Wild West" kind of interpretation of civil life that doesn't necessarily map to other societies - and even the days of "Wild West" are long over, aren't they ;-)
To me, the main purpose of CoCs is not the text itself. It's getting organizers thinking about how they would react to possible issues upfront.
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Experts (#1, Feb 29 2016)
Python Projects, Coaching and Consulting ... http://www.egenix.com/ Python Database Interfaces ... http://products.egenix.com/ Plone/Zope Database Interfaces ... http://zope.egenix.com/
2016-02-19: Released eGenix PyRun 2.1.2 ... http://egenix.com/go88
::: We implement business ideas - efficiently in both time and costs :::
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/ http://www.malemburg.com/
On 02/29/2016 12:09 PM, M.-A. Lemburg wrote:
This is the part about all this CoC talk I never understand. Why on earth would someone change their regular behavior when "at a meetup or conference that has not implemented a CoC" ?
Sadly, there are plenty of people who act wildly differently depending on where they are.
To me, the main purpose of CoCs is not the text itself. It's getting organizers thinking about how they would react to possible issues upfront.
Definitely.
-- ~Ethan~
On Mon, 29 Feb 2016 at 12:10 M.-A. Lemburg <mal@egenix.com> wrote:
... If we happen to be at a meetup or conference that has not implemented a CoC
On 29.02.2016 18:38, Brett Cannon wrote: that
shouldn't give us an excuse as esteemed representatives of this language and community to be lax in our behaviour since how we act as core devs is probably amplified compared to others in the community.
This is the part about all this CoC talk I never understand. Why on earth would someone change their regular behavior when "at a meetup or conference that has not implemented a CoC" ?
This sounds to me like a very "Wild West" kind of interpretation of civil life that doesn't necessarily map to other societies - and even the days of "Wild West" are long over, aren't they ;-)
To me, the main purpose of CoCs is not the text itself. It's getting organizers thinking about how they would react to possible issues upfront.
How about this then: we make it policy that all core-involved "stuff' -- mailing lists, issue tracker, etc. -- are to be explicitly put under the PSF CoC? I think python-dev and bugs.python.org are things we control which do not explicitly follow the PSF CoC (I have an email to python-dev-owner@ to get get python-dev updated but I have not heard back; <nudge> :). We could also, as policy, put all projects under the python organization on GitHub -- existing and future -- under the PSF CoC by adding an appropriate CONTRIBUTING file to the repositories.
On 02/28/2016 11:10 AM, Brett Cannon wrote:
I swear that I did not mean to pull a fast one or somehow exert some influence to make this happen on the sly and I'm sorry if you thought that; I seriously thought it wasn't going to be an issue. But since it is for some I promise I won't make any change to the devguide unless clear consensus can be reached or Guido tells me to flat-out (just like any other change that affects Python).
+1 for CoC. Better to have expectations written down so nobody has to guess.
-- ~Ethan~
On Sun, Feb 28, 2016 at 07:10:18PM +0000, Brett Cannon wrote:
On Sat, 27 Feb 2016 at 18:33 Steven D'Aprano <steve@pearwood.info> wrote:
[...]
You could have, should have, waited a few days before seemingly ramming this policy change in behind people's backs.
Steven, I didn't try to sneak this past anyone.
I can give you nothing less than full credit for not generally abusing your list admin powers. And I do believe that you think you are acting in the best interests of the group. But even the most innocent actions can *seem* suspicious, which is why I used the words I used: "seemingly ... behind people's backs".
I can believe that the timing of a Friday night was an unfortunate coincidence. But the objection isn't about that, or even about the CoC itself. I know that I'm in a minority here. If this had come down to a vote, or community consensus, you probably would have got your CoC approved. I'm a grown-up, I know I can't get my way all the time. But in a community that claims to welcome diverse opinions, I do expect that we all should be given the opportunity to express those opinions when it matters -- and not just reduced to complaining afterwards.
This exact objection has come up before, when you and Titus decided to apply the CoC on the Python-Ideas list in 2013, and announced it to the list as a done deal.
Brett, I know that you have de facto powers that the rest of us don't, by virtue of being a list admin. You're an elite among elites. Do the CoC principles of openess, respect and consideration apply to elites too? Then you should have been open to opposing viewpoints; you should have given the community the respect and consideration of asking for community feedback before imposing this change of rule.
The honest truth is, if you had said "If nobody strongly objects by Monday my time, two days from now, I'll take that as consensus in favour and apply the CoC" I probably wouldn't even have argued against it. (I only have so much energy for tilting at windmills, and I have to pick the most important ones.)
[...]
This is an international group, and I'm an Australian, and the language I use with my wife, friends and co-workers is far more forthright and strong than the language I use here. But if I slip occasionally, and call a spade a bloody shovel as they say, I don't want those with more restrictive, less enlightened or even merely different standards to be able to formally rebuke me. Why should I have to change my behaviour more than I already do? Why can't they be a bit more flexible and accepting of differences and less judgmental?
There is a massive difference between using a word that someone might consider a swear word and regularly being mean or disrespectful.
I'm afraid you misunderstand me. To call a spade a bloody shovel is not about using "swear words". It is about being frank, direct and blunt, even brusque, without sugar-coating the message, beating around the bush or using euphemisms. It's not even a uniquely Australian saying:
1964 J. Reston in N.Y. Times 14 Feb. IV 8: The time has come to call a spade a bloody shovel. This country is in an undeclared and unexplained war in Vietnam. Our masters have a lot of long and fancy names for it [...] but it is war just the same.
Sometimes people take offence at direct language. Call a piece of software "crap", or even "a jenky mess", and some people will say that you're being rude and disruptive. I do not hold with that view.
[...]
I swear that I did not mean to pull a fast one or somehow exert some influence to make this happen on the sly and I'm sorry if you thought that;
Brett I unconditionally believe you and I too am sorry that I didn't make it clear enough that I was talking about the *perception* of sneakiness rather than actual sneakiness.
I think I've made it clear that I am not a supporter of the CoC, but I am a supporter of the principles it sets forth. (And if anyone thinks this is an insane contradictory position to take, I'm happy to discuss it off-list.) I fully expect that had you asked for comments prior to making the change, they would have been overwhelmingly in favour.
Nevertheless, I believe that you should have asked first. Not because you have to (you are list admin, and you are physically capable of doing whatever you like to the list), but because failing to consult with the community goes against the principles of the CoC.
-- Steve
On Sat, Feb 27, 2016 at 7:17 PM, Brett Cannon <brett@python.org> wrote:
Python-ideas has been under the same CoC for a while now and it has been nothing but positive. When people know they are expected to behave in a civil manner and others know they are allowed to call someone out for being uncivil it typically is enough to make people behave.
So there is no issue of people "being overburdened by regulations". The CoC only comes up when someone is being so rude that they need to be talked to about their attitude problem, so as long as we try and keep people from being rude it won't come up. Quite frankly, the CoC is really just meant as a way for people to feel comfortable in knowing they don't have to tolerate jerks. And I would hope none of us are jerks to people in the community, so saying as much shouldn't change anything for any of us. This also lets the community know that we don't view ourselves as some elite group of people whose attitudes must be tolerated no matter what; we hold ourselves to the same standards as the rest of the community does and it should be pointed out as such to make people feel comfortable.
It seems to me that the "controversies" raised in this thread stem from a few underlying problems and points of confusions.
The first problem is that it is not entirely clear (at least to me) why we need a CoC and what problem is the CoC trying to solve. The CoC itself simply mentions: "[...] these guidelines [...] help steer our interactions and strive to keep Python a positive, successful, and growing community.". Clearly stating the goal of the CoC will help people understand why it is useful.
The second problem is that Code of Conducts usually outline rules[0], and this can be perceived as limiting one's freedom and potentially be abused for censoring users. Our CoC however is quite "mild", so I believe people that expressed concern were mostly against the idea of having a CoC, rather than being against our CoC in particular. However is also not clear what measures -- if any -- will be taken to enforce the CoC[1].
Which bring us to the the third problem: if, how, and by whom these "guidelines" are enforced. Enforcement requires judgment, and judgment requires judges. Who is to judge if e.g. one or more mails in broken English, or with a perceived rude tone, or with unrealistic proposals are detrimental to the conversation and should be "rejected" or if they should be accepted/tolerated/embraced in the spirit of inclusiveness? If they are "rejected", what specific actions are going to be taken?
ISTM that our CoC simply puts black on white the general principles that we have already being following, without outlining any hard rules. It should therefore have little to no effects -- both positive and negative -- on existing members. It might however serve as a remainder to people that disregard (intentionally or not) these principles, and help shaping the image of our community for external people -- including potential new members of our community.
Best Regards, Ezio Melotti
[0]: "A code of conduct is a set of rules outlining the social norms and rules and responsibilities of, or proper practices for, an individual, party or organization." -- https://en.wikipedia.org/wiki/Code_of_conduct
[1]: "Studies of codes of conduct in the private sector show that their effective implementation must be part of a learning process that requires training, consistent enforcement, and continuous measurement/improvement." -- https://en.wikipedia.org/wiki/Code_of_conduct
On 06.03.2016 17:52, Ezio Melotti wrote:
On Sat, Feb 27, 2016 at 7:17 PM, Brett Cannon <brett@python.org> wrote:
Python-ideas has been under the same CoC for a while now and it has been nothing but positive. When people know they are expected to behave in a civil manner and others know they are allowed to call someone out for being uncivil it typically is enough to make people behave.
So there is no issue of people "being overburdened by regulations". The CoC only comes up when someone is being so rude that they need to be talked to about their attitude problem, so as long as we try and keep people from being rude it won't come up. Quite frankly, the CoC is really just meant as a way for people to feel comfortable in knowing they don't have to tolerate jerks. And I would hope none of us are jerks to people in the community, so saying as much shouldn't change anything for any of us. This also lets the community know that we don't view ourselves as some elite group of people whose attitudes must be tolerated no matter what; we hold ourselves to the same standards as the rest of the community does and it should be pointed out as such to make people feel comfortable.
It seems to me that the "controversies" raised in this thread stem from a few underlying problems and points of confusions.
The first problem is that it is not entirely clear (at least to me) why we need a CoC and what problem is the CoC trying to solve. The CoC itself simply mentions: "[...] these guidelines [...] help steer our interactions and strive to keep Python a positive, successful, and growing community.". Clearly stating the goal of the CoC will help people understand why it is useful.
The second problem is that Code of Conducts usually outline rules[0], and this can be perceived as limiting one's freedom and potentially be abused for censoring users. Our CoC however is quite "mild", so I believe people that expressed concern were mostly against the idea of having a CoC, rather than being against our CoC in particular. However is also not clear what measures -- if any -- will be taken to enforce the CoC[1].
Which bring us to the the third problem: if, how, and by whom these "guidelines" are enforced. Enforcement requires judgment, and judgment requires judges. Who is to judge if e.g. one or more mails in broken English, or with a perceived rude tone, or with unrealistic proposals are detrimental to the conversation and should be "rejected" or if they should be accepted/tolerated/embraced in the spirit of inclusiveness? If they are "rejected", what specific actions are going to be taken?
FYI: I only know of a single case where we have triggered the CoC to ban someone from MLs. The decision was taken by the PSF board members who ultimately have to decide these things (or delegate the decision to someone else).
The board deliberately put the bar very high for any such sanctions.
ISTM that our CoC simply puts black on white the general principles that we have already being following, without outlining any hard rules. It should therefore have little to no effects -- both positive and negative -- on existing members. It might however serve as a remainder to people that disregard (intentionally or not) these principles, and help shaping the image of our community for external people -- including potential new members of our community.
Best Regards, Ezio Melotti
[0]: "A code of conduct is a set of rules outlining the social norms and rules and responsibilities of, or proper practices for, an individual, party or organization." -- https://en.wikipedia.org/wiki/Code_of_conduct
[1]: "Studies of codes of conduct in the private sector show that their effective implementation must be part of a learning process that requires training, consistent enforcement, and continuous measurement/improvement." -- https://en.wikipedia.org/wiki/Code_of_conduct
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Experts (#1, Mar 06 2016)
Python Projects, Coaching and Consulting ... http://www.egenix.com/ Python Database Interfaces ... http://products.egenix.com/ Plone/Zope Database Interfaces ... http://zope.egenix.com/
2016-02-19: Released eGenix PyRun 2.1.2 ... http://egenix.com/go88
::: We implement business ideas - efficiently in both time and costs :::
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/ http://www.malemburg.com/
On 27.02.2016 13:07, Stefan Krah wrote:
Brett Cannon <brett <at> python.org> writes:
I noticed that the devguide didn't explicitly mention that core developers were expected to follow the PSF CoC (https://docs.python.org/devguide/coredev.html and https://www.python.org/psf/codeofconduct/, respectively). I have opened http://bugs.python.org/issue26446 to make sure it gets documented. Since this is technically a modification of the requirements of getting commit privileges I wanted to mention it here before I (or anyone else) made the change.
When I started here, the PSF and python-dev were considered disjoint entities (quoting MvL from memory). Looking at
https://www.python.org/psf/records/board/history/ ,
half of the current directors have never appeared anywhere on the python-dev infrastructure, most notably on python-checkins.
Contrast this with e.g. the period of 2003-2004, where I still know all of the directors even though I did not know Python at that time!
Some very prolific contributors do not appear in the list of PSF members at all.
This particular CoC specifically addresses conference misbehavior, which is fine.
The PSF CoC has a focus on community interaction, not on conferences. It's different from eg. the PyCon US conference CoC.
No CoC short of an 800 page volume can address the many forms of human shortcomings in more complex situations. I'm not going to go into detail here, but "suaviter in modo, fortiter in re", even though usually depicted as desirable behavior, can easily lead to more stagnation and friction than occasional superficial impoliteness.
I think python-dev should remain an entity where interested people can just come and "hack on something" instead of being overburdened by regulations.
As for the devguide, briefly mentioning the categorical imperative should suffice. ;)
While I don't like the term "code of conduct", I do believe that the text itself provides a reasonable summary of what we all expect from Python community interactions. It's certainly more easily comprehensible than philosophical models of moral and ethics such as Kant's categorical imperative or the more modern discourse ethics of Habermas.
Mix all that with a good dose of Monty Python's don't-take-yourself- too-seriously, add some Tim Peters takes-one-to-know-one-ly and I believe we can all be on the same page :-)
Hmm, perhaps we ought to make reading some Python humor a prerequisite for core developers instead...
https://www.python.org/doc/humor/
Only-half-joking-ly,
Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Experts (#1, Feb 27 2016)
Python Projects, Coaching and Consulting ... http://www.egenix.com/ Python Database Interfaces ... http://products.egenix.com/ Plone/Zope Database Interfaces ... http://zope.egenix.com/
2016-02-19: Released eGenix PyRun 2.1.2 ... http://egenix.com/go88
::: We implement business ideas - efficiently in both time and costs :::
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/ http://www.malemburg.com/
M.-A. Lemburg <mal <at> egenix.com> writes:
This particular CoC specifically addresses conference misbehavior, which is fine.
The PSF CoC has a focus on community interaction, not on conferences. It's different from eg. the PyCon US conference CoC.
Consider me schooled. :)
Mix all that with a good dose of Monty Python's don't-take-yourself- too-seriously, add some Tim Peters takes-one-to-know-one-ly and I believe we can all be on the same page
Hmm, perhaps we ought to make reading some Python humor a prerequisite for core developers instead...
I would throw in "Life of Brian" (in particular the "we are all individuals" dialogue) and "Yes Minister" (don't get me started on that one).
Wondering what a Monty Python episode about CoCs would look like ...
Stefan Krah
On Tue, Mar 1, 2016 at 10:17 AM, Stefan Krah <stefan@bytereef.org> wrote:
Wondering what a Monty Python episode about CoCs would look like ...
I think you're misunderstanding Monty Python's humour if you think they'd have made one about the CoC :) They were very much for punching upward, not kicking downward. They ridiculed themselves and the environments they came from, not those thinking of others. Certainly not measures taken to make the playing field more open and clear for everyone. (Contrast with, say, South Park, which inherited Monty Python's visual humour with an entirely different stance on social responsibility ;P)
-- Thomas Wouters <thomas@python.org>
Hi! I'm an email virus! Think twice before sending your email to help me spread!
Le 01/03/2016 10:33, Thomas Wouters a écrit :
On Tue, Mar 1, 2016 at 10:17 AM, Stefan Krah <stefan@bytereef.org <mailto:stefan@bytereef.org>> wrote:
Wondering what a Monty Python episode about CoCs would look like ...I think you're misunderstanding Monty Python's humour if you think they'd have made one about the CoC :) They were very much for punching upward, not kicking downward.
Why would ridiculing a CoC have anything to do about kicking downward? Promoters of CoCs are certainly mostly found in the same social classes as their detractors.
Monty Python have ridiculed militant practices and jargon in the past (e.g. the anarcho-syndicalist commune in Holy Grail, or the various Liberation Fronts in Life Of Brian). I'm sure if the CoC frenzy had appeared in the 1970s they'd have made fun of it too.
Note ridiculing a CoC is not the same thing as ridiculing marginalized people, just as ridiculing a self-proclaimed "Workers' Party" is not the same thing as ridiculing factory workers.
Regards
Antoine.
Le 01/03/2016 10:50, Antoine Pitrou a écrit :
Monty Python have ridiculed militant practices and jargon in the past (e.g. the anarcho-syndicalist commune in Holy Grail, or the various Liberation Fronts in Life Of Brian). I'm sure if the CoC frenzy had appeared in the 1970s they'd have made fun of it too.
Btw I'll admit the word "frenzy" isn't very fortunate here. CoCs certainly have their uses. It would be nice if people like Anita Sarkeesian didn't have to go through insults and threats every day...
Regards
Antoine.
On Tue, Mar 1, 2016 at 10:17 AM, Stefan Krah <stefan <at> bytereef.org> wrote:Wondering what a Monty Python episode about CoCs would look like ...
I think you're misunderstanding Monty Python's humour if you think they'd have made one about the CoC :) They were very much for punching upward, not kicking downward. They ridiculed themselves and the environments they came from, not those thinking of others. Certainly not measures taken to make the
Thomas Wouters <thomas <at> python.org> writes: playing field more open and clear for everyone. (Contrast with, say, South Park, which inherited Monty Python's visual humour with an entirely different stance on social responsibility ;P)
Sorry, this is a huge strawman. Core developers are already very much on a level playing field. If you want, I can post a IRC log where people who are undoubtedly in favor of the CoC a) gossip about two core devs, b) ask if said core-devs "had any influence", and c) make fun of the works of said core-devs.
Some of these people have impeccable manners on mailing lists, and not addressing Machiavellianism is one of the most glaring flaws of this CoC.
I'm quite upset about you bringing in "kicking downward" (even if qualified by a smiley).
Stefan Krah
On Tue, Mar 1, 2016 at 10:51 AM, Stefan Krah <stefan@bytereef.org> wrote:
Sorry, this is a huge strawman. Core developers are already very much on a level playing field.
The intent of the CoC isn't just about protecting the current community members. It's also about making it open and inviting to *new members*. The core-dev community, despite best efforts, can easily be seen as an "good old boys club". Making it clear that we don't *intend* for it to be that way is a good step to make.
If you want, I can post a IRC log where people who are undoubtedly in favor of the CoC a) gossip about two core devs, b) ask if said core-devs "had any influence", and c) make fun of the works of said core-devs.
All the more reason to point them to the CoC and ask if they would be more considerate.
Some of these people have impeccable manners on mailing lists, and not addressing Machiavellianism is one of the most glaring flaws of this CoC.
It's proven quite hard to draft a CoC -- or any document -- that everyone agrees to *and* covers everything everyone wants. I wish it were more explicit about certain things, and more condemning, but I'm glad to have it to refer to anyway. (I frequently refer to it on #python on Freenode.)
I'm quite upset about you bringing in "kicking downward" (even if qualified by a smiley).
It was not meant as a personal attack, merely a reaction to what I perceived as you making light of the idea of a CoC. I see that I was mistaken, so I'm sorry.
-- Thomas Wouters <thomas@python.org>
Hi! I'm an email virus! Think twice before sending your email to help me spread!
On Saturday, February 27, 2016, Stefan Krah <stefan@bytereef.org> wrote:
Brett Cannon <brett <at> python.org> writes:
I noticed that the devguide didn't explicitly mention that core developers were expected to follow the PSF CoC (https://docs.python.org/devguide/coredev.html and https://www.python.org/psf/codeofconduct/, respectively). I have opened http://bugs.python.org/issue26446 to make sure it gets documented. Since this is technically a modification of the requirements of getting commit privileges I wanted to mention it here before I (or anyone else) made the change.
When I started here, the PSF and python-dev were considered disjoint entities (quoting MvL from memory). Looking at
https://www.python.org/psf/records/board/history/ ,
half of the current directors have never appeared anywhere on the python-dev infrastructure, most notably on python-checkins.
Contrast this with e.g. the period of 2003-2004, where I still know all of the directors even though I did not know Python at that time!
Some very prolific contributors do not appear in the list of PSF members at all.
This particular CoC specifically addresses conference misbehavior, which is fine.
FYI It has nothing to do with conferences.
Hi,
2016-02-26 20:29 GMT+01:00 Brett Cannon <brett@python.org>:
I noticed that the devguide didn't explicitly mention that core developers were expected to follow the PSF CoC (https://docs.python.org/devguide/coredev.html and https://www.python.org/psf/codeofconduct/, respectively). I have opened http://bugs.python.org/issue26446 to make sure it gets documented.
Since this is technically a modification of the requirements of getting commit privileges I wanted to mention it here before I (or anyone else) made the change.
I'm fine with this change. Especially core developers must respect the CoC, give the example ;-)
Victor
On 2/28/2016 3:56 PM, Victor Stinner wrote:
Hi,
2016-02-26 20:29 GMT+01:00 Brett Cannon <brett@python.org>:
I noticed that the devguide didn't explicitly mention that core developers were expected to follow the PSF CoC (https://docs.python.org/devguide/coredev.html and https://www.python.org/psf/codeofconduct/, respectively). I have opened http://bugs.python.org/issue26446 to make sure it gets documented.
Since this is technically a modification of the requirements of getting commit privileges I wanted to mention it here before I (or anyone else) made the change.
I'm fine with this change. Especially core developers must respect the CoC, give the example ;-)
+1, for reasons of other examples.
tjr
The discussion about the Code of Conduct has sputtered out, so I'm going to assume those who care to speak up have at this point. It seems to me that the general agreement is that putting python-dev and bugs.python.org under the CoC might not solve any real issues we currently have, but it won't hurt anything either (and both python-committers and python-ideas are already covered). And since the CoC might make some people feel more comfortable in participating, that means going ahead and flipping on the CoC where we reasonably can.
So what I will do is try to convince the managers of python-dev to put it under the CoC and get the CoC mentioned in the footer of bugs.python.org. I will update the devguide to say that the various mailing lists and issue tracker are under the CoC so people are aware, but I won't go as far as I was originally proposing about covering all public, Python-related interactions. Once we move to GitHub we will most likely have a CONTRIBUTING file that links to the devguide and that file will mention that interactions involving the repo are under the CoC (or some other wording that says pull requests fall under the Code of Conduct).
On Fri, 26 Feb 2016 at 11:29 Brett Cannon <brett@python.org> wrote:
I noticed that the devguide didn't explicitly mention that core developers were expected to follow the PSF CoC ( https://docs.python.org/devguide/coredev.html and https://www.python.org/psf/codeofconduct/, respectively). I have opened http://bugs.python.org/issue26446 to make sure it gets documented.
Since this is technically a modification of the requirements of getting commit privileges I wanted to mention it here before I (or anyone else) made the change.
Brett,
I don't think that spamming all MLs, Github accounts, etc. with CoC notices will help anyone.
You may not be aware, but all PSF infrastructure is covered by the PSF CoC already, and has been for quite a while:
""" RESOLVED, that the Python Software Foundation shall manage and curate the Foundation's public and member-accessible web properties to remove spam, serve the membership, and conform to the the Python Community Code of Conduct.
Approved 9-0-0 by IRC vote, 3 January, 2014. """
All PSF members have acknowledged this and adding yet another notice to each and every point of interaction will not make things better.
If there are issues, point people to the CoC. Otherwise, let's not get all tangled up in CoC links everywhere :-)
We can get the 16 ton weight out when needed...
https://www.youtube.com/watch?v=U90dnUbZMmM
and optionally even send the tiger.
Cheers,
Marc-Andre Lemburg
On 04.03.2016 22:31, Brett Cannon wrote:
The discussion about the Code of Conduct has sputtered out, so I'm going to assume those who care to speak up have at this point. It seems to me that the general agreement is that putting python-dev and bugs.python.org under the CoC might not solve any real issues we currently have, but it won't hurt anything either (and both python-committers and python-ideas are already covered). And since the CoC might make some people feel more comfortable in participating, that means going ahead and flipping on the CoC where we reasonably can.
So what I will do is try to convince the managers of python-dev to put it under the CoC and get the CoC mentioned in the footer of bugs.python.org. I will update the devguide to say that the various mailing lists and issue tracker are under the CoC so people are aware, but I won't go as far as I was originally proposing about covering all public, Python-related interactions. Once we move to GitHub we will most likely have a CONTRIBUTING file that links to the devguide and that file will mention that interactions involving the repo are under the CoC (or some other wording that says pull requests fall under the Code of Conduct).
On Fri, 26 Feb 2016 at 11:29 Brett Cannon <brett@python.org> wrote:
I noticed that the devguide didn't explicitly mention that core developers were expected to follow the PSF CoC ( https://docs.python.org/devguide/coredev.html and https://www.python.org/psf/codeofconduct/, respectively). I have opened http://bugs.python.org/issue26446 to make sure it gets documented.
Since this is technically a modification of the requirements of getting commit privileges I wanted to mention it here before I (or anyone else) made the change.
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Experts (#1, Mar 04 2016)
Python Projects, Coaching and Consulting ... http://www.egenix.com/ Python Database Interfaces ... http://products.egenix.com/ Plone/Zope Database Interfaces ... http://zope.egenix.com/
2016-02-19: Released eGenix PyRun 2.1.2 ... http://egenix.com/go88
::: We implement business ideas - efficiently in both time and costs :::
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/ http://www.malemburg.com/
On Fri, 4 Mar 2016 at 14:04 M.-A. Lemburg <mal@egenix.com> wrote:
Brett,
I don't think that spamming all MLs, Github accounts, etc. with CoC notices will help anyone.
Which is not what I'm suggesting nor would I want to do unless it's a stated change in policy so people feel properly notified.
You may not be aware, but all PSF infrastructure is covered by the PSF CoC already, and has been for quite a while:
""" RESOLVED, that the Python Software Foundation shall manage and curate the Foundation's public and member-accessible web properties to remove spam, serve the membership, and conform to the the Python Community Code of Conduct.
Approved 9-0-0 by IRC vote, 3 January, 2014. """
That's great, but how are people to know this if they don't read the minutes of the board? Is it considered too much if I link to the minutes in the devguide so people know about this ( https://www.python.org/psf/records/board/minutes/2014-01-06/#management-of-t... )?
All PSF members have acknowledged this and adding yet another notice to each and every point of interaction will not make things better.
I'm not worried about PSF members, it's all the new folk who are just "walking off the street" and are looking to contribute.
If there are issues, point people to the CoC. Otherwise, let's not get all tangled up in CoC links everywhere :-)
Fair enough, but I would like at least one canonical location to link to that bit of the minutes so that it's somewhere a bit more public. Is a link in the devguide considered acceptable?
-Brett
We can get the 16 ton weight out when needed...
https://www.youtube.com/watch?v=U90dnUbZMmM
and optionally even send the tiger.
Cheers,
Marc-Andre Lemburg
On 04.03.2016 22:31, Brett Cannon wrote:
The discussion about the Code of Conduct has sputtered out, so I'm going to assume those who care to speak up have at this point. It seems to me that the general agreement is that putting python-dev and bugs.python.org under the CoC might not solve any real issues we currently have, but it won't hurt anything either (and both python-committers and python-ideas are already covered). And since the CoC might make some people feel more comfortable in participating, that means going ahead and flipping on the CoC where we reasonably can.
So what I will do is try to convince the managers of python-dev to put it under the CoC and get the CoC mentioned in the footer of bugs.python.org. I will update the devguide to say that the various mailing lists and issue tracker are under the CoC so people are aware, but I won't go as far as I was originally proposing about covering all public, Python-related interactions. Once we move to GitHub we will most likely have a CONTRIBUTING file that links to the devguide and that file will mention that interactions involving the repo are under the CoC (or some other wording that says pull requests fall under the Code of Conduct).
On Fri, 26 Feb 2016 at 11:29 Brett Cannon <brett@python.org> wrote:
I noticed that the devguide didn't explicitly mention that core developers were expected to follow the PSF CoC ( https://docs.python.org/devguide/coredev.html and https://www.python.org/psf/codeofconduct/, respectively). I have opened http://bugs.python.org/issue26446 to make sure it gets documented.
Since this is technically a modification of the requirements of getting commit privileges I wanted to mention it here before I (or anyone else) made the change.
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Experts (#1, Mar 04 2016)
Python Projects, Coaching and Consulting ... http://www.egenix.com/ Python Database Interfaces ... http://products.egenix.com/ Plone/Zope Database Interfaces ... http://zope.egenix.com/
2016-02-19: Released eGenix PyRun 2.1.2 ... http://egenix.com/go88
::: We implement business ideas - efficiently in both time and costs :::
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/ http://www.malemburg.com/
On 05.03.2016 00:40, Brett Cannon wrote:
On Fri, 4 Mar 2016 at 14:04 M.-A. Lemburg <mal@egenix.com> wrote:
Brett,
I don't think that spamming all MLs, Github accounts, etc. with CoC notices will help anyone.
Which is not what I'm suggesting nor would I want to do unless it's a stated change in policy so people feel properly notified.
I was referring to adding CoC links to all ML footers (causing it to appeary on each and every ML message), all Github repos, etc.
I think this is not helpful. It's better to have a single page on the python.org where we state how we use the CoC and perhaps a footer link on python.org pointing to it.
Perhaps we don't even need a new page and simply use the existing CoC page for this, by adding some more text to it and perhaps a FAQ section.
You may not be aware, but all PSF infrastructure is covered by the PSF CoC already, and has been for quite a while:
""" RESOLVED, that the Python Software Foundation shall manage and curate the Foundation's public and member-accessible web properties to remove spam, serve the membership, and conform to the the Python Community Code of Conduct.
Approved 9-0-0 by IRC vote, 3 January, 2014. """
That's great, but how are people to know this if they don't read the minutes of the board? Is it considered too much if I link to the minutes in the devguide so people know about this ( https://www.python.org/psf/records/board/minutes/2014-01-06/#management-of-t... )?
If needed at all, it's better to link to above yet-to-be-written page.
All PSF members have acknowledged this and adding yet another notice to each and every point of interaction will not make things better.
I'm not worried about PSF members, it's all the new folk who are just "walking off the street" and are looking to contribute.
If there are issues, point people to the CoC. Otherwise, let's not get all tangled up in CoC links everywhere :-)
Fair enough, but I would like at least one canonical location to link to that bit of the minutes so that it's somewhere a bit more public. Is a link in the devguide considered acceptable?
-Brett
We can get the 16 ton weight out when needed...
https://www.youtube.com/watch?v=U90dnUbZMmM
and optionally even send the tiger.
Cheers,
Marc-Andre Lemburg
On 04.03.2016 22:31, Brett Cannon wrote:
The discussion about the Code of Conduct has sputtered out, so I'm going to assume those who care to speak up have at this point. It seems to me that the general agreement is that putting python-dev and bugs.python.org under the CoC might not solve any real issues we currently have, but it won't hurt anything either (and both python-committers and python-ideas are already covered). And since the CoC might make some people feel more comfortable in participating, that means going ahead and flipping on the CoC where we reasonably can.
So what I will do is try to convince the managers of python-dev to put it under the CoC and get the CoC mentioned in the footer of bugs.python.org. I will update the devguide to say that the various mailing lists and issue tracker are under the CoC so people are aware, but I won't go as far as I was originally proposing about covering all public, Python-related interactions. Once we move to GitHub we will most likely have a CONTRIBUTING file that links to the devguide and that file will mention that interactions involving the repo are under the CoC (or some other wording that says pull requests fall under the Code of Conduct).
On Fri, 26 Feb 2016 at 11:29 Brett Cannon <brett@python.org> wrote:
I noticed that the devguide didn't explicitly mention that core developers were expected to follow the PSF CoC ( https://docs.python.org/devguide/coredev.html and https://www.python.org/psf/codeofconduct/, respectively). I have opened http://bugs.python.org/issue26446 to make sure it gets documented.
Since this is technically a modification of the requirements of getting commit privileges I wanted to mention it here before I (or anyone else) made the change.
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Experts (#1, Mar 04 2016)
Python Projects, Coaching and Consulting ... http://www.egenix.com/ Python Database Interfaces ... http://products.egenix.com/ Plone/Zope Database Interfaces ... http://zope.egenix.com/
2016-02-19: Released eGenix PyRun 2.1.2 ... http://egenix.com/go88
::: We implement business ideas - efficiently in both time and costs :::
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/ http://www.malemburg.com/
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Experts (#1, Mar 06 2016)
Python Projects, Coaching and Consulting ... http://www.egenix.com/ Python Database Interfaces ... http://products.egenix.com/ Plone/Zope Database Interfaces ... http://zope.egenix.com/
2016-02-19: Released eGenix PyRun 2.1.2 ... http://egenix.com/go88
::: We implement business ideas - efficiently in both time and costs :::
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/ http://www.malemburg.com/
On Sun, 6 Mar 2016 at 10:13 M.-A. Lemburg <mal@egenix.com> wrote:
On 05.03.2016 00:40, Brett Cannon wrote:
On Fri, 4 Mar 2016 at 14:04 M.-A. Lemburg <mal@egenix.com> wrote:
Brett,
I don't think that spamming all MLs, Github accounts, etc. with CoC notices will help anyone.
Which is not what I'm suggesting nor would I want to do unless it's a stated change in policy so people feel properly notified.
I was referring to adding CoC links to all ML footers (causing it to appeary on each and every ML message), all Github repos, etc.
I think this is not helpful. It's better to have a single page on the python.org where we state how we use the CoC and perhaps a footer link on python.org pointing to it.
Perhaps we don't even need a new page and simply use the existing CoC page for this, by adding some more text to it and perhaps a FAQ section.
That works for me as well. Did you want the board to amend the CoC with the relevant details or did you want me to just directly edit the coc repo?
You may not be aware, but all PSF infrastructure is covered by the PSF CoC already, and has been for quite a while:
""" RESOLVED, that the Python Software Foundation shall manage and
curate
the Foundation's public and member-accessible web properties to remove spam, serve the membership, and conform to the the Python Community Code of Conduct.
Approved 9-0-0 by IRC vote, 3 January, 2014. """
That's great, but how are people to know this if they don't read the minutes of the board? Is it considered too much if I link to the minutes in the devguide so people know about this (
https://www.python.org/psf/records/board/minutes/2014-01-06/#management-of-t...
)?
If needed at all, it's better to link to above yet-to-be-written page.
WFM.
-Brett
All PSF members have acknowledged this and adding yet another notice to each and every point of interaction will not make things better.
I'm not worried about PSF members, it's all the new folk who are just "walking off the street" and are looking to contribute.
If there are issues, point people to the CoC. Otherwise, let's not get all tangled up in CoC links everywhere :-)
Fair enough, but I would like at least one canonical location to link to that bit of the minutes so that it's somewhere a bit more public. Is a link in the devguide considered acceptable?
-Brett
We can get the 16 ton weight out when needed...
https://www.youtube.com/watch?v=U90dnUbZMmM
and optionally even send the tiger.
Cheers,
Marc-Andre Lemburg
On 04.03.2016 22:31, Brett Cannon wrote:
The discussion about the Code of Conduct has sputtered out, so I'm
to
assume those who care to speak up have at this point. It seems to me
the general agreement is that putting python-dev and bugs.python.org under the CoC might not solve any real issues we currently have, but it won't hurt anything either (and both python-committers and python-ideas are already covered). And since the CoC might make some people feel more comfortable in participating, that means going ahead and flipping on
going that the
CoC where we reasonably can.
So what I will do is try to convince the managers of python-dev to put it under the CoC and get the CoC mentioned in the footer of bugs.python.org. I will update the devguide to say that the various mailing lists and issue tracker are under the CoC so people are aware, but I won't go as far as I was originally proposing about covering all public, Python-related interactions. Once we move to GitHub we will most likely have a CONTRIBUTING file that links to the devguide and that file will mention that interactions involving the repo are under the CoC (or some other wording that says pull requests fall under the Code of Conduct).
On Fri, 26 Feb 2016 at 11:29 Brett Cannon <brett@python.org> wrote:
I noticed that the devguide didn't explicitly mention that core developers were expected to follow the PSF CoC ( https://docs.python.org/devguide/coredev.html and https://www.python.org/psf/codeofconduct/, respectively). I have opened http://bugs.python.org/issue26446 to make sure it gets documented.
Since this is technically a modification of the requirements of getting commit privileges I wanted to mention it here before I (or anyone else) made the change.
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Experts (#1, Mar 04 2016)
Python Projects, Coaching and Consulting ... http://www.egenix.com/ Python Database Interfaces ... http://products.egenix.com/ Plone/Zope Database Interfaces ... http://zope.egenix.com/
2016-02-19: Released eGenix PyRun 2.1.2 ... http://egenix.com/go88
::: We implement business ideas - efficiently in both time and costs :::
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/ http://www.malemburg.com/
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Experts (#1, Mar 06 2016)
Python Projects, Coaching and Consulting ... http://www.egenix.com/ Python Database Interfaces ... http://products.egenix.com/ Plone/Zope Database Interfaces ... http://zope.egenix.com/
2016-02-19: Released eGenix PyRun 2.1.2 ... http://egenix.com/go88
::: We implement business ideas - efficiently in both time and costs :::
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/ http://www.malemburg.com/
On Fri, 04 Mar 2016 21:31:44 +0000, Brett Cannon <brett@python.org> wrote:
The discussion about the Code of Conduct has sputtered out, so I'm going to assume those who care to speak up have at this point. It seems to me that the general agreement is that putting python-dev and bugs.python.org under the CoC might not solve any real issues we currently have, but it won't hurt anything either (and both python-committers and python-ideas are already covered). And since the CoC might make some people feel more comfortable in participating, that means going ahead and flipping on the CoC where we reasonably can.
I guess I have one more thing to say.
Thinking about this, I realized that in fact this emphasis on the CoC is making me feel less like contributing. I doesn't feel like a large effect, but it is real[*]. Just thought you should know :)
--David
[*] I think it is a feeling of annoyance, like I'm being nagged for no good reason, inclining me to turn my attention away instead of joyfully engaging. Talking about how welcoming the Python community is, and how we can be more so, engenders joy. Talking about codes of conduct engenders annoyance. Regardless of the reality, it *feels* like the bureaucrats have moved in and are squashing the native aliveness of the community.
On 03/04/2016 03:07 PM, R. David Murray wrote:
I guess I have one more thing to say.
[snip]
[*] I think it is a feeling of annoyance, like I'm being nagged for no good reason [...]
I'm inclined to agree, but some bureaucracy is the price of success. Be grateful somebody else is willing to do the work of getting it in place, so we don't have to. ;)
-- ~Ethan~
On Fri, 4 Mar 2016 at 15:07 R. David Murray <rdmurray@bitdance.com> wrote:
On Fri, 04 Mar 2016 21:31:44 +0000, Brett Cannon <brett@python.org> wrote:
The discussion about the Code of Conduct has sputtered out, so I'm going to assume those who care to speak up have at this point. It seems to me that the general agreement is that putting python-dev and bugs.python.org under the CoC might not solve any real issues we currently have, but it won't hurt anything either (and both python-committers and python-ideas are already covered). And since the CoC might make some people feel more comfortable in participating, that means going ahead and flipping on the CoC where we reasonably can.
I guess I have one more thing to say.
Thinking about this, I realized that in fact this emphasis on the CoC is making me feel less like contributing. I doesn't feel like a large effect, but it is real[*]. Just thought you should know :)
I'm sorry if that's what this thread has caused for you, David, and it's obviously not what I'm after.
I guess I'm just worried about the health of this project. I'm doing what I can through the migration to GitHub to make it easier for others to get involved while making it easier for us to accept the work of others, but the maintenance and health of this team worries me. For instance, if you look at the developer's log you will notice we only gained 2 core devs for all of 2015 and the last one was August 2015: https://docs.python.org/devguide/developers.html. 2013 was the next slowest year with 4, but most years are much closer to 10 than 0. We also still have no female or minority members.
Now I'm not advocating for some quota for adding new members or that they have to meet some minority group status, but we should be aware of this and perhaps ask why this is. When I thought about this the other week after a cranky email to python-dev appeared I realized that the CoC isn't exactly advertised so that people know they shouldn't act mean here like they might in other corners of the internet where it's tolerated. I thought perhaps if we took this one time to make it officially in effect then it would remove at least one tiny barrier that might be holding up people from getting more involved. I certainly don't want any morality police, but I do want people to know that Python development is not one of the mean, cesspool corners of the internet either. And so I figured adding a link at the bottom of a couple of things would be a minor thing and a nice gesture to newcomers. I didn't mean for it to seem like a perpetual burden for anyone or a deterrent to contributing.
-Brett
--David
[*] I think it is a feeling of annoyance, like I'm being nagged for no good reason, inclining me to turn my attention away instead of joyfully engaging. Talking about how welcoming the Python community is, and how we can be more so, engenders joy. Talking about codes of conduct engenders annoyance. Regardless of the reality, it *feels* like the bureaucrats have moved in and are squashing the native aliveness of the community.
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
On Fri, Mar 4, 2016 at 5:07 PM, Brett Cannon <brett@python.org> wrote:
When I thought about this the other week after a cranky email to python-dev appeared I realized that the CoC isn't exactly advertised so that people know they shouldn't act mean here like they might in other corners of the internet where it's tolerated. I thought perhaps if we took this one time to make it officially in effect then it would remove at least one tiny barrier that might be holding up people from getting more involved. I certainly don't want any morality police, but I do want people to know that Python development is not one of the mean, cesspool corners of the internet either. And so I figured adding a link at the bottom of a couple of things would be a minor thing and a nice gesture to newcomers. I didn't mean for it to seem like a perpetual burden for anyone or a deterrent to contributing.
Perhaps it would be sufficient to reference the CoC on each list's page rather than in each email footer. Then it's not so in-your-face (not that I had visually noticed that it was already added on recently).
-eric
On Fri, 04 Mar 2016 21:31:44 +0000, Brett Cannon <brett@python.org> wrote:
I guess I'm just worried about the health of this project. I'm doing what I can through the migration to GitHub to make it easier for others to get involved while making it easier for us to accept the work of others, but the maintenance and health of this team worries me. For instance, if you look at the developer's log you will notice we only gained 2 core devs for all of 2015 and the last one was August 2015: https://docs.python.org/devguide/developers.html. 2013 was the next slowest year with 4, but most years are much closer to 10 than 0. We also still have no female or minority members.
Remember how new committers happen: current committers notice their contributions on the tracker, suggest they be given the commit bit and offer to mentor them, and we take a poll. The critical bits here are (1) noticing and (2) being willing to mentor. So, if we want more committers, current ones need to put forth the effort to monitor active bugs, evaluate prospects, and recommend and mentor them. And hopefully do some mentoring via the bug tracker to get more people commit-bit ready.
This is a catch 22: we need more active committers in order to get more active committers. But we know that; that question is what to do about it.
I the past few years I've monitored the bug tracker fairly closely, and watched for good prospects, and recommended or inspired the recommendation of several. Right now I don't have the time to monitor the bug tracker the way I had been and watch people the way I had been, so I won't be in a position to recommend anyone for the next while....
--David
PS: Actually, let me throw out that the people that had been at the top of my list before I stopped were eryksun, paul.j3 (for argparse), and davin (for multiprocessing). And I suspect maciej.szulik is also a candidate once we've seen a few more patches from him. (And I need to find the time to review the ones he has already submitted in the email area.)
Someone or ones should look at tracker activity by username and see if they can find some more candidates.
In article <20160305043104.60898B1401C@webabinitio.net>, "R. David Murray" <rdmurray@bitdance.com> wrote:
Remember how new committers happen: current committers notice their contributions on the tracker, suggest they be given the commit bit and offer to mentor them, and we take a poll. The critical bits here are (1) noticing and (2) being willing to mentor. So, if we want more committers, current ones need to put forth the effort to monitor active bugs, evaluate prospects, and recommend and mentor them. And hopefully do some mentoring via the bug tracker to get more people commit-bit ready.
This is a catch 22: we need more active committers in order to get more active committers. But we know that; that question is what to do about it.
I the past few years I've monitored the bug tracker fairly closely, and watched for good prospects, and recommended or inspired the recommendation of several. Right now I don't have the time to monitor the bug tracker the way I had been and watch people the way I had been, so I won't be in a position to recommend anyone for the next while....
I don't think any of us truly understand how much time you have put into this kind of behind-the-scenes activity over the years nor fully appreciate how important that has been to the on-going success of python-dev. Thanks, David.
PS: Actually, let me throw out that the people that had been at the top of my list before I stopped were eryksun, paul.j3 (for argparse), and davin (for multiprocessing).
I agree with your recommendations for all three.
-- Ned Deily, nad@python.org
On 05.03.16 10:18, Ned Deily wrote:
In article <20160305043104.60898B1401C@webabinitio.net>, "R. David Murray" <rdmurray@bitdance.com> wrote:
I the past few years I've monitored the bug tracker fairly closely, and watched for good prospects, and recommended or inspired the recommendation of several. Right now I don't have the time to monitor the bug tracker the way I had been and watch people the way I had been, so I won't be in a position to recommend anyone for the next while....
I don't think any of us truly understand how much time you have put into this kind of behind-the-scenes activity over the years nor fully appreciate how important that has been to the on-going success of python-dev. Thanks, David.
Want to join the acknowledgement. David's work is invaluable.
PS: Actually, let me throw out that the people that had been at the top of my list before I stopped were eryksun, paul.j3 (for argparse), and davin (for multiprocessing).
I agree with your recommendations for all three.
I haven't been following the activity in the argparse module, but I'm watching Eryk Sun and was going to offer his candidacy if it will retain his activity over the next few months.
On Mar 4, 2016, at 4:07 PM, Brett Cannon <brett@python.org> wrote:
I guess I'm just worried about the health of this project. I'm doing what I can through the migration to GitHub to make it easier for others to get involved while making it easier for us to accept the work of others, but the maintenance and health of this team worries me. For instance, if you look at the developer's log you will notice we only gained 2 core devs for all of 2015 and the last one was August 2015:
Last year on this list, I recommended that Davin Potts be granted core developer status for his on-going work on the multiprocessing module. This group collectively said no, leaving Davin in an odd and uncomfortable limbo.
The social barriers to entry proved too high even for an seasoned open source developer, the former chief scientist at Continuum, who had already devoted substantial time to reviewing the 100+ tracker entries for multiprocessing, who had expressed a willingness to handle complex and neglected tasks, and who was recommended by an active core developer.
If someone of his stature faces an uphill battle, then perhaps there is reason to worry.
Raymond
On Fri, Mar 4, 2016 at 10:07 PM Raymond Hettinger < raymond.hettinger@gmail.com> wrote:
On Mar 4, 2016, at 4:07 PM, Brett Cannon <brett@python.org> wrote:
I guess I'm just worried about the health of this project. I'm doing what I can through the migration to GitHub to make it easier for others to get involved while making it easier for us to accept the work of others, but the maintenance and health of this team worries me. For instance, if you look at the developer's log you will notice we only gained 2 core devs for all of 2015 and the last one was August 2015:
Last year on this list, I recommended that Davin Potts be granted core developer status for his on-going work on the multiprocessing module. This group collectively said no, leaving Davin in an odd and uncomfortable limbo.
Huh? Searching for Davin Potts in my mail, I see a ~27 message long thread from January 2015 about that. Many of us were +1 to give him commit rights.
I personally assumed it had happened, but the only objections seemed to be "lets see some patches first"... That part has happened:
Among the *other* things in my mail with Davin's name mentioned are several streams of committed patches over the past year or so on multiprocessing related issues (as expected), including recently.
berker.peksag, martin.panter and serhiy.storchaka have been the primary committers of said Davin patches.
Let's get Davin a commit bit.
-gps
On Sat, Mar 5, 2016 at 8:44 AM, Gregory P. Smith <greg@krypto.org> wrote:
On Fri, Mar 4, 2016 at 10:07 PM Raymond Hettinger <raymond.hettinger@gmail.com> wrote:
On Mar 4, 2016, at 4:07 PM, Brett Cannon <brett@python.org> wrote:
I guess I'm just worried about the health of this project. I'm doing what I can through the migration to GitHub to make it easier for others to get involved while making it easier for us to accept the work of others, but the maintenance and health of this team worries me. For instance, if you look at the developer's log you will notice we only gained 2 core devs for all of 2015 and the last one was August 2015:
Last year on this list, I recommended that Davin Potts be granted core developer status for his on-going work on the multiprocessing module. This group collectively said no, leaving Davin in an odd and uncomfortable limbo.
Huh? Searching for Davin Potts in my mail, I see a ~27 message long thread from January 2015 about that. Many of us were +1 to give him commit rights.
I personally assumed it had happened, but the only objections seemed to be "lets see some patches first"... That part has happened:
Among the other things in my mail with Davin's name mentioned are several streams of committed patches over the past year or so on multiprocessing related issues (as expected), including recently.
berker.peksag, martin.panter and serhiy.storchaka have been the primary committers of said Davin patches.
+1!
I was going to send an email to python-committers about this a couple weeks ago, but I couldn't find enough time (or I was just lazy :)) to collect issue numbers (he did a great job on triaging old multiprocessing issues) and commits.
I'm willing to mentor/co-mentor him if there's no other candidate.
--Berker
On 05.03.16 09:21, Berker Peksağ wrote:
On Sat, Mar 5, 2016 at 8:44 AM, Gregory P. Smith <greg@krypto.org> wrote:
On Fri, Mar 4, 2016 at 10:07 PM Raymond Hettinger <raymond.hettinger@gmail.com> wrote:
On Mar 4, 2016, at 4:07 PM, Brett Cannon <brett@python.org> wrote:
I guess I'm just worried about the health of this project. I'm doing what I can through the migration to GitHub to make it easier for others to get involved while making it easier for us to accept the work of others, but the maintenance and health of this team worries me. For instance, if you look at the developer's log you will notice we only gained 2 core devs for all of 2015 and the last one was August 2015:
Last year on this list, I recommended that Davin Potts be granted core developer status for his on-going work on the multiprocessing module. This group collectively said no, leaving Davin in an odd and uncomfortable limbo.
Huh? Searching for Davin Potts in my mail, I see a ~27 message long thread from January 2015 about that. Many of us were +1 to give him commit rights.
I personally assumed it had happened, but the only objections seemed to be "lets see some patches first"... That part has happened:
Among the other things in my mail with Davin's name mentioned are several streams of committed patches over the past year or so on multiprocessing related issues (as expected), including recently.
berker.peksag, martin.panter and serhiy.storchaka have been the primary committers of said Davin patches.
+1!
I was going to send an email to python-committers about this a couple weeks ago, but I couldn't find enough time (or I was just lazy :)) to collect issue numbers (he did a great job on triaging old multiprocessing issues) and commits.
+1 from me. I have committed not too much Davin's patches (they were not easy), but confirm his proficiency. We need an expert in this domain.
Who wants to be Davin's mentor and tell him to do the steps outlined in https://docs.python.org/devguide/coredev.html#gaining-commit-privileges ?
On Sat, 5 Mar 2016 at 01:04 Serhiy Storchaka <storchaka@gmail.com> wrote:
On Sat, Mar 5, 2016 at 8:44 AM, Gregory P. Smith <greg@krypto.org> wrote:
On Fri, Mar 4, 2016 at 10:07 PM Raymond Hettinger <raymond.hettinger@gmail.com> wrote:
On Mar 4, 2016, at 4:07 PM, Brett Cannon <brett@python.org> wrote:
I guess I'm just worried about the health of this project. I'm doing what I can through the migration to GitHub to make it easier for others to get involved while making it easier for us to accept the work of others, but the maintenance and health of this team worries me. For instance, if you look at the developer's log you will notice we only gained 2 core devs for all of 2015 and the last one was August 2015:
Last year on this list, I recommended that Davin Potts be granted core developer status for his on-going work on the multiprocessing module. This group collectively said no, leaving Davin in an odd and uncomfortable
Huh? Searching for Davin Potts in my mail, I see a ~27 message long
On 05.03.16 09:21, Berker Peksağ wrote: limbo. thread
from January 2015 about that. Many of us were +1 to give him commit rights.
I personally assumed it had happened, but the only objections seemed to be "lets see some patches first"... That part has happened:
Among the other things in my mail with Davin's name mentioned are several streams of committed patches over the past year or so on multiprocessing related issues (as expected), including recently.
berker.peksag, martin.panter and serhiy.storchaka have been the primary committers of said Davin patches.
+1!
I was going to send an email to python-committers about this a couple weeks ago, but I couldn't find enough time (or I was just lazy :)) to collect issue numbers (he did a great job on triaging old multiprocessing issues) and commits.
+1 from me. I have committed not too much Davin's patches (they were not easy), but confirm his proficiency. We need an expert in this domain.
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
On Mar 5, 2016, at 8:51 AM, Brett Cannon <brett@python.org> wrote:
Who wants to be Davin's mentor and tell him to do the steps outlined in https://docs.python.org/devguide/coredev.html#gaining-commit-privileges ?
Davin already knows what to do, he just needs the commit bit flipped.
FWIW, I had volunteered for any needed mentorship 15 months ago but that didn't seem to affect the outcome of the conversation.
Raymond
On Sat, 5 Mar 2016 at 17:59 Raymond Hettinger <raymond.hettinger@gmail.com> wrote:
On Mar 5, 2016, at 8:51 AM, Brett Cannon <brett@python.org> wrote:
Who wants to be Davin's mentor and tell him to do the steps outlined in https://docs.python.org/devguide/coredev.html#gaining-commit-privileges ?
Davin already knows what to do, he just needs the commit bit flipped.
It's a bit more involved than that since he needs to send his SSH key(s) to hgaccounts@python.org (which can also simply be his GitHub account since https://github.com/<username>.keys lists one's keys registered with GitHub), tell us what his name is for the hg account, and tell us what email address he wants to subscribe to python-committers with. Then he will get listed in the devguide at https://docs.python.org/devguide/developers.html and get his flag flipped on the issue tracker as a committer (and I assume his username is "davin"). That's the kind of stuff listed at the URL I sent you, not how to make a commit happen.
FWIW, I had volunteered for any needed mentorship 15 months ago but that didn't seem to affect the outcome of the conversation.
Finding someone a mentor is a necessary but not sufficient condition to getting someone commit privileges. It's great that you were willing to vouch for Davin 15 months ago, Raymond, but he simply had to gain more people's trust before we as a group were ready to give him commit privileges. That's now happened and so we are getting him the privileges he has demonstrated he is capable of having.
Does your offer to mentor Davin still stand, or would you rather someone else take Davin on to double-check his first few commits follow our development process?
On Sun, 6 Mar 2016 at 00:23 Raymond Hettinger <raymond.hettinger@gmail.com> wrote:
On Mar 5, 2016, at 10:13 PM, Brett Cannon <brett@python.org> wrote:
Does your offer to mentor Davin still stand,
Yes.
Great! Then as I said previously, get him to send his SSH keys to hgaccounts@python.org, verify for me that his username is "davin" on bugs.python.org, and have him subscribe to python-committers and friends, and I will handle the rest.
On Mar 5, 2016, at 01:44, Gregory P. Smith <greg@krypto.org> wrote:
I personally assumed it had happened, but the only objections seemed to be "lets see some patches first"... That part has happened:
Among the other things in my mail with Davin's name mentioned are several streams of committed patches over the past year or so on multiprocessing related issues (as expected), including recently.
berker.peksag, martin.panter and serhiy.storchaka have been the primary committers of said Davin patches.
Let's get Davin a commit bit.
+1, Davin has been doing a great job supporting multiprocessing
-- Ned Deily nad@python.org -- []
Le 05/03/2016 07:07, Raymond Hettinger a écrit :
On Mar 4, 2016, at 4:07 PM, Brett Cannon <brett@python.org> wrote:
I guess I'm just worried about the health of this project. I'm doing what I can through the migration to GitHub to make it easier for others to get involved while making it easier for us to accept the work of others, but the maintenance and health of this team worries me. For instance, if you look at the developer's log you will notice we only gained 2 core devs for all of 2015 and the last one was August 2015:
Last year on this list, I recommended that Davin Potts be granted core
developer status for his on-going work on the multiprocessing module. This group collectively said no, leaving Davin in an odd and uncomfortable limbo.
This is a partial way to put it. You recommended Davin while he had no experience contributing to CPython. This was why your proposal was rejected, and it was the only decent answer to your proposal IMHO. It is unfair to promote people on the basis of their sole name or professional occupation (not to mention that those can be very inefficient criteria in practice...), all the while asking others to prove themselves through patches and code reviews.
(see https://mail.python.org/pipermail/python-committers/2015-January/003240.html -- note mail.p.o seems down here and now)
If we want contributors to feel they are treated equally and decently regardless of their personal acquaintances or non-CPython experiences, then we should continue judging them on the basis of their actual contributions, not some a priori positive feelings about them. I think most people on this list agree this is necessary.
Regards
Antoine.
On 03/05/2016 01:07 AM, Brett Cannon wrote:
On Fri, 4 Mar 2016 at 15:07 R. David Murray <rdmurray@bitdance.com <mailto:rdmurray@bitdance.com>> wrote:
On Fri, 04 Mar 2016 21:31:44 +0000, Brett Cannon <brett@python.org <mailto:brett@python.org>> wrote: > The discussion about the Code of Conduct has sputtered out, so I'm going to > assume those who care to speak up have at this point. It seems to me that > the general agreement is that putting python-dev and bugs.python.org <http://bugs.python.org> under > the CoC might not solve any real issues we currently have, but it won't > hurt anything either (and both python-committers and python-ideas are > already covered). And since the CoC might make some people feel more > comfortable in participating, that means going ahead and flipping on the > CoC where we reasonably can. I guess I have one more thing to say. Thinking about this, I realized that in fact this emphasis on the CoC is making me feel less like contributing. I doesn't feel like a large effect, but it is real[*]. Just thought you should know :)I'm sorry if that's what this thread has caused for you, David, and it's obviously not what I'm after.
I guess I'm just worried about the health of this project. I'm doing what I can through the migration to GitHub to make it easier for others to get involved while making it easier for us to accept the work of others, but the maintenance and health of this team worries me. For instance, if you look at the developer's log you will notice we only gained 2 core devs for all of 2015 and the last one was August 2015: https://docs.python.org/devguide/developers.html. 2013 was the next slowest year with 4, but most years are much closer to 10 than 0. We also still have no female or minority members.
Not sure how you determined the latter. There are many kinds of minorities.
Anyway, with the migration to Git it becomes much easier to spot and remind us of potential committers, as both author and committer info are retained in commits. This makes a periodic report (by a bot, presumably) possible that lists those authors with the most commits, but without commit bit.
cheers, Georg
On Sat, 5 Mar 2016 at 10:58 Georg Brandl <g.brandl@gmx.net> wrote:
On 03/05/2016 01:07 AM, Brett Cannon wrote:
On Fri, 4 Mar 2016 at 15:07 R. David Murray <rdmurray@bitdance.com <mailto:rdmurray@bitdance.com>> wrote:
On Fri, 04 Mar 2016 21:31:44 +0000, Brett Cannon <brett@python.org <mailto:brett@python.org>> wrote: > The discussion about the Code of Conduct has sputtered out, so I'mgoing to
> assume those who care to speak up have at this point. It seems tome that
> the general agreement is that putting python-dev andbugs.python.org
<http://bugs.python.org> under > the CoC might not solve any real issues we currently have, but itwon't
> hurt anything either (and both python-committers and python-ideasare
> already covered). And since the CoC might make some people feelmore
> comfortable in participating, that means going ahead and flippingon the
> CoC where we reasonably can. I guess I have one more thing to say. Thinking about this, I realized that in fact this emphasis on theCoC is
making me feel less like contributing. I doesn't feel like a large effect, but it is real[*]. Just thought you should know :)I'm sorry if that's what this thread has caused for you, David, and it's obviously not what I'm after.
I guess I'm just worried about the health of this project. I'm doing
through the migration to GitHub to make it easier for others to get involved while making it easier for us to accept the work of others, but the
what I can maintenance
and health of this team worries me. For instance, if you look at the developer's log you will notice we only gained 2 core devs for all of 2015 and the last one was August 2015: https://docs.python.org/devguide/developers.html. 2013 was the next slowest year with 4, but most years are much closer to 10 than 0. We also still have no female or minority members.
Not sure how you determined the latter. There are many kinds of minorities.
Anyway, with the migration to Git it becomes much easier to spot and remind us of potential committers, as both author and committer info are retained in commits. This makes a periodic report (by a bot, presumably) possible that lists those authors with the most commits, but without commit bit.
That's a great idea! Recorded in PEP 512: https://hg.python.org/peps/rev/fad7b646ab06.
On 6 March 2016 at 06:52, Brett Cannon <brett@python.org> wrote:
On Sat, 5 Mar 2016 at 10:58 Georg Brandl <g.brandl@gmx.net> wrote:
Anyway, with the migration to Git it becomes much easier to spot and remind us of potential committers, as both author and committer info are retained in commits. This makes a periodic report (by a bot, presumably) possible that lists those authors with the most commits, but without commit bit.
That's a great idea! Recorded in PEP 512: https://hg.python.org/peps/rev/fad7b646ab06.
Bonus points if the bot can figure out how many iterations the patch went through prior to being merged - when I've recommended folks for commit bits in the past, it's generally been because I've got to a point where I feel like I'm just rubberstamping their patches (rather than needing to suggest changes), so I can be confident they've worked out for themselves what "good" looks like.
(Such a bot would be useful even without that though, as the folks actually reviewing and merging the commits would still be the ones to propose new contributors for merge privileges)
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Sat, 5 Mar 2016 at 18:15 Nick Coghlan <ncoghlan@gmail.com> wrote:
On 6 March 2016 at 06:52, Brett Cannon <brett@python.org> wrote:
On Sat, 5 Mar 2016 at 10:58 Georg Brandl <g.brandl@gmx.net> wrote:
Anyway, with the migration to Git it becomes much easier to spot and remind us of potential committers, as both author and committer info are retained in commits. This makes a periodic report (by a bot, presumably) possible that lists those authors with the most commits, but without commit bit.
That's a great idea! Recorded in PEP 512: https://hg.python.org/peps/rev/fad7b646ab06.
Bonus points if the bot can figure out how many iterations the patch went through prior to being merged - when I've recommended folks for commit bits in the past, it's generally been because I've got to a point where I feel like I'm just rubberstamping their patches (rather than needing to suggest changes), so I can be confident they've worked out for themselves what "good" looks like.
It's called a "synchronize" action for the pull request, so yes, it can be tracked. :)
-Brett
(Such a bot would be useful even without that though, as the folks actually reviewing and merging the commits would still be the ones to propose new contributors for merge privileges)
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (22)
-
Alexander Belopolsky -
Antoine Pitrou -
Berker Peksağ -
Brett Cannon -
Brian Curtin -
Eric Snow -
Ethan Furman -
Ezio Melotti -
Georg Brandl -
Gregory P. Smith -
M.-A. Lemburg -
Ned Deily -
Nick Coghlan -
Paul Moore -
R. David Murray -
Raymond Hettinger -
Serhiy Storchaka -
Stefan Krah -
Steven D'Aprano -
Terry Reedy -
Thomas Wouters -
Victor Stinner