Sorry to see you go, Stefan. You will be missed. -- H On Wed, 7 Oct 2020 at 14:50, Antoine Pitrou wrote:

Hello,

Apparently, Stefan Krah (core developer and author of the C _decimal module) was silently banned or moderated from posting to python.org mailing-lists. He asked me to forward the following message:

================================================================================== Hello,

Today I have left the Python organization. It wasn't an easy decision, after all there are so many amazing people here.

My vision of how development should be handled differs from many people who are currently active. Other projects are more aligned with my preferences, so I prefer to focus my energies elsewhere.

Having a shared understanding of what constitutes politeness is important and eliminates all sources of friction that sometimes result in losing one's patience.

All the best,

Stefan Krah

====================================================================================

Best regards

Antoine. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/ZIAN7ERZ... Code of Conduct: http://python.org/psf/codeofconduct/

-- OpenPGP: https://sks-keyservers.net/pks/lookup?op=get&search=0xFEBAD7FFD041BBA1 If you wish to request my time, please do so using *bit.ly/hd1AppointmentRequest http://bit.ly/hd1AppointmentRequest*. Si vous voudrais faire connnaisance, allez a *bit.ly/hd1AppointmentRequest http://bit.ly/hd1AppointmentRequest*. https://sks-keyservers.net/pks/lookup?op=get&search=0xFEBAD7FFD041BBA1Sent from my mobile device Envoye de mon portable

I don't see the point of requiring to "write an apology", especially *before a 12-month ban*. If they understand that their behavior is wrong, there's no need for a ban, at least not such a long one; if they don't, they clearly aren't going to write it, at least not now (they might later, after a few weeks or months, having cooled down and thought it over). So all it would achieve is public shaming AFAICS. Same issue with the threat of "zero tolerance policy" -- it's completely unnecessary and only serves to humiliate and alienate the recipient. Cf. https://en.wikipedia.org/wiki/Wikipedia:Blocking_policy#Purpose_and_goals, specifically: "blocks should not be punitive, blocks should be preventative". (Btw thanks for publishing the letter. This is done very rarely so issues like this most often go unnoticed.) On 09.10.2020 2:07, Thomas Wouters wrote:

Stefan did indeed receive, and was notified of, a 1-year ban from core development. This action was based on advice from the Conduct WG and our own deliberations. We wanted to have a discussion with him before we made this public. The SC sent him an email with details (quoted below), three weeks ago, CC'ing the Conduct WG. We had a brief back-and-forth last week. Unfortunately (and without telling us), Stefan apparently declined to address the matter in the way we asked.

For the record, the Steering Council followed the PEP 13 procedure for ejecting a core developer (https://www.python.org/dev/peps/pep-0013/#ejecting-core-team-members) and voted unanimously to eject Stefan, as we told Stefan we would do if he chose not to address the concerns we outlined below.

Our original message to Stefan: """ Dear Stefan,

The Python Steering Council and the PSF Conduct Working Group have received reports of your ongoing behavior in the Python core developer community. The Steering Council agrees with the Conduct Working Group’s findings that this behavior is unacceptable. While we appreciate your valuable technical contributions to CPython, that does not exempt you from the expected standards of behavior and the Code of Conduct.

Specifically, your behavior has displayed:

* Disrespectful, hostile, and unwelcoming communication in tone and content * Harassment by needlessly adding people to issues * A disregard of the directions and authority of the release manager

Some examples of the problematic behavior include:

* https://bugs.python.org/issue36839#msg344544 * https://bugs.python.org/issue40874#msg372616 * https://bugs.python.org/issue40874#msg372917 * https://bugs.python.org/issue40874#msg372922 * https://bugs.python.org/issue39542#msg372983

We are also aware that this is not new behavior. We know the PSF Conduct WG warned you on April 23, 2020 about your previous violations of the Code of Conduct.

As such, we are taking the action of suspending your participation in Python's development for 12 months starting today. You will lose access to:

* Python-committers * Python-dev * Python-ideas * Core-mentorship * bugs.python.org http://bugs.python.org * discuss.python.org http://discuss.python.org * The Python organization on GitHub

Along with the 12-month suspension, you will need to meet additional conditions in good faith:

* Please acknowledge that you have read and understand the Code of Conduct and promise to abide by it going forward * You write an apology to your fellow core developers for your actions which we will publish on your behalf when announcing your suspension * Acknowledge that future reinstatement will include a zero-tolerance conduct policy in regards to your future behavior

We offer you 14 days from today to meet these conditions and submit them to the Steering Council via email.

If you choose not to satisfy these conditions, the 12-month suspension will become a permanent ejection from the Python core developer community as per the procedures outlined in PEP 13.  You are then free to go through the Python core developer election process also as outlined in PEP 13, however the Steering Council will not consider approving any positive outcome of that vote until the 12-month suspension has elapsed.

- The Python Steering Council """

On behalf of the Steering Council, Thomas.

On Wed, Oct 7, 2020 at 11:48 PM Antoine Pitrou mailto:antoine@python.org> wrote:

Hello,

Apparently, Stefan Krah (core developer and author of the C _decimal module) was silently banned or moderated from posting to python.org http://python.org mailing-lists.  He asked me to forward the following message:

================================================================================== Hello,

Today I have left the Python organization.  It wasn't an easy decision, after all there are so many amazing people here.

My vision of how development should be handled differs from many people who are currently active.  Other projects are more aligned with my preferences, so I prefer to focus my energies elsewhere.

Having a shared understanding of what constitutes politeness is important and eliminates all sources of friction that sometimes result in losing one's patience.

All the best,

Stefan Krah ====================================================================================

Best regards

Antoine. _______________________________________________ python-committers mailing list -- python-committers@python.org mailto:python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org mailto:python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/Z... Code of Conduct: https://www.python.org/psf/codeofconduct/

-- Thomas Wouters mailto:thomas@python.org>

Hi! I'm an email virus! Think twice before sending your email to help me spread!

_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/BSFWGLR4... Code of Conduct: http://python.org/psf/codeofconduct/ -- Regards, Ivan

On 09/10/2020 04.04, Ivan Pozdeev via Python-Dev wrote:

I don't see the point of requiring to "write an apology", especially *before a 12-month ban*. If they understand that their behavior is wrong, there's no need for a ban, at least not such a long one; if they don't, they clearly aren't going to write it, at least not now (they might later, after a few weeks or months, having cooled down and thought it over). So all it would achieve is public shaming AFAICS. Same issue with the threat of "zero tolerance policy" -- it's completely unnecessary and only serves to humiliate and alienate the recipient.

I have been the victim of Stefan's CoC violations on more than one occasion. He added me to nosy list of a ticket just to offend and humiliate me. For this reason I personally asked the SC to make a sincere apology a mandatory requirement for Stefan's reinstatement as a core dev. I would have been fine with a private apology. However Stefan has also verbally attacked non-core contributors. In one case another core dev and I contacted the contribute in private to apologize and ensure that the contributor was not alienated by Stefan's attitude. Therefore it makes sense that the SC has requested a public, general apology. Why are you more concerned with the reputation of a repeated offender and not with the feelings of multiple victims of harassment? As a victim of Stefan's behavior I feel that an apology is the first step to reconcile and rebuild trust. Christian

On 09/10/2020 15.48, Antoine Pitrou wrote:

On Fri, 9 Oct 2020 05:04:55 +0300 Ivan Pozdeev via Python-Dev wrote:

...

I don't see the point of requiring to "write an apology", especially *before a 12-month ban*. If they understand that their behavior is wrong, there's no need for a ban, at least not such a long one; if they don't, they clearly aren't going to write it, at least not now (they might later, after a few weeks or months, having cooled down and thought it over). So all it would achieve is public shaming AFAICS. Same issue with the threat of "zero tolerance policy" -- it's completely unnecessary and only serves to humiliate and alienate the recipient.

That's my impression as well. Also, we now have an unmaintained module (_decimal) requiring specific competence.

Please elaborate. I feel like you are insinuating something with your "unmaintained module" remark.

----- Original Message -----

From: "Antoine Pitrou" To: python-dev@python.org Sent: Friday, October 9, 2020 4:02:51 PM Subject: [Python-Dev] Re: [python-committers] Resignation from Stefan Krah

Le 09/10/2020 à 15:57, Christian Heimes a écrit :

...

On 09/10/2020 15.48, Antoine Pitrou wrote:

...

On Fri, 9 Oct 2020 05:04:55 +0300 Ivan Pozdeev via Python-Dev wrote:

...

I don't see the point of requiring to "write an apology", especially *before a 12-month ban*. If they understand that their behavior is wrong, there's no need for a ban, at least not such a long one; if they don't, they clearly aren't going to write it, at least not now (they might later, after a few weeks or months, having cooled down and thought it over). So all it would achieve is public shaming AFAICS. Same issue with the threat of "zero tolerance policy" -- it's completely unnecessary and only serves to humiliate and alienate the recipient.

That's my impression as well. Also, we now have an unmaintained module (_decimal) requiring specific competence.

Please elaborate. I feel like you are insinuating something with your "unmaintained module" remark.

Well, it's not hard to notice that Stefan was the maintainer (as well as the primary or sole author) of the C _decimal module, right?

I think that is irrelevant to the decision of the steering council though.

I wouldn't say for sure, but I don't expect him to transmit patches through a third party, now that the SC banned him for 12 months, and that he publicly resigned (signalling that he has probably no intention to try to come back).

Do you think otherwise? Or do you think there's someone else ready to take up maintenance? Are you volunteering for that?

Does it really matter that much in regards to the specific context? If someone poses problematic behavior (as it seems, as I'm not familiar with any specifics here), maintenance of a module should be the last of the worries. There are many pieces in the stdlib which remain or have remained unmaintained for years. Maybe someone could pick up the pace, maybe not.

Regards

Antoine. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/5WX63I23... Code of Conduct: http://python.org/psf/codeofconduct/

-- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat

On Fri, Oct 9, 2020 at 7:23 AM Charalampos Stratakis wrote:

...

From: "Antoine Pitrou" To: python-dev@python.org Sent: Friday, October 9, 2020 4:02:51 PM Subject: [Python-Dev] Re: [python-committers] Resignation from Stefan Krah

Le 09/10/2020 à 15:57, Christian Heimes a écrit :

...

On 09/10/2020 15.48, Antoine Pitrou wrote:

...

On Fri, 9 Oct 2020 05:04:55 +0300 Ivan Pozdeev via Python-Dev wrote:

...

I don't see the point of requiring to "write an apology", especially *before a 12-month ban*. If they understand that their behavior is wrong, there's no need for a ban, at least not such a long one; if

...

...

...

...

don't, they clearly aren't going to write it, at least not now (they might later, after a few weeks or months, having cooled down and

----- Original Message ----- they thought

...

...

...

...

it over). So all it would achieve is public shaming AFAICS. Same issue with the threat of "zero tolerance policy" -- it's completely unnecessary and only serves to humiliate and alienate the recipient.

That's my impression as well. Also, we now have an unmaintained module (_decimal) requiring specific competence.

Please elaborate. I feel like you are insinuating something with your "unmaintained module" remark.

Well, it's not hard to notice that Stefan was the maintainer (as well as the primary or sole author) of the C _decimal module, right?

I think that is irrelevant to the decision of the steering council though.

We did thank Stefan in the email for his technical contributions, but being the primary contributor to a module in the stdlib should not give you leeway to be mean to others compared to anyone else (nor should any technical contributions for that matter). So I agree with Charalampos that it's irrelevant.

...

I wouldn't say for sure, but I don't expect him to transmit patches through a third party, now that the SC banned him for 12 months, and that he publicly resigned (signalling that he has probably no intention to try to come back).

Do you think otherwise? Or do you think there's someone else ready to take up maintenance? Are you volunteering for that?

Does it really matter that much in regards to the specific context? If someone poses problematic behavior (as it seems, as I'm not familiar with any specifics here), maintenance of a module should be the last of the worries. There are many pieces in the stdlib which remain or have remained unmaintained for years. Maybe someone could pick up the pace, maybe not.

Another way to look at this is to realize that Stefan's behaviour may have scared off people who would have been willing to contribute to the decimal module. As Christian pointed out, there is already one instance of a contributor who he felt needed to be followed up with to make sure they were okay. As much as we know they could have become a major contributor to 'decimal' and this specific concern wouldn't even exist. -Brett

...

Regards

Antoine. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at

https://mail.python.org/archives/list/python-dev@python.org/message/5WX63I23...

...

Code of Conduct: http://python.org/psf/codeofconduct/

-- Regards,

Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/6QCFOVUS... Code of Conduct: http://python.org/psf/codeofconduct/

On Fri, Oct 9, 2020 at 12:05 PM David Mertz wrote:

On Fri, Oct 9, 2020 at 10:25 AM Charalampos Stratakis wrote:

...

Does it really matter that much in regards to the specific context? If someone poses problematic behavior (as it seems, as I'm not familiar with any specifics here), maintenance of a module should be the last of the worries. There are many pieces in the stdlib which remain or have remained unmaintained for years. Maybe someone could pick up the pace, maybe not.

I agree with Charalampos here. I am NOT opining on any specifics of problematic behavior or the SCs actions.

But many module contributors or maintainers become unavailable for many different reasons. We cannot, and should not, rest these broader collaboration decisions on some specific expertise, which we cannot guarantee will remain regardless of SC actions. If needed, hopefully someone else can pick up _decimal. But the same principle applies to any module mostly maintained by anyone else who has contributed. Things happen in people's life, quite independent of CoC issues.

This is also why the SC has emphasized multiple times that no one "owns" anything in CPython. We obviously have experts, but spreading knowledge is an important part to maintaining a large, open source project like this. If that hasn't happened for _decimal then that's something to fix. And to put a very fine point on it: we literally had a primary maintainer of a module die, so there is absolutely zero guarantee that someone will ever come back to contribute past their last contribution. -Brett

-- The dead increasingly dominate and strangle both the living and the not-yet born. Vampiric capital and undead corporate persons abuse the lives and control the thoughts of homo faber. Ideas, once born, become abortifacients against new conceptions. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/2UQX46YP... Code of Conduct: http://python.org/psf/codeofconduct/

On 09.10.2020 15:28, Christian Heimes wrote:

On 09/10/2020 04.04, Ivan Pozdeev via Python-Dev wrote:

...

I don't see the point of requiring to "write an apology", especially *before a 12-month ban*. If they understand that their behavior is wrong, there's no need for a ban, at least not such a long one; if they don't, they clearly aren't going to write it, at least not now (they might later, after a few weeks or months, having cooled down and thought it over). So all it would achieve is public shaming AFAICS. Same issue with the threat of "zero tolerance policy" -- it's completely unnecessary and only serves to humiliate and alienate the recipient.

I have been the victim of Stefan's CoC violations on more than one occasion. He added me to nosy list of a ticket just to offend and humiliate me. For this reason I personally asked the SC to make a sincere apology a mandatory requirement for Stefan's reinstatement as a core dev.

As a requirement for _reinstatement_ , it does make sense.

I would have been fine with a private apology. However Stefan has also verbally attacked non-core contributors. In one case another core dev and I contacted the contribute in private to apologize and ensure that the contributor was not alienated by Stefan's attitude. Therefore it makes sense that the SC has requested a public, general apology.

Why are you more concerned with the reputation of a repeated offender and not with the feelings of multiple victims of harassment? As a victim of Stefan's behavior I feel that an apology is the first step to reconcile and rebuild trust.

Christian -- Regards, Ivan

On Fri, Oct 9, 2020 at 2:50 PM Toshio Kuratomi wrote:

On Fri, Oct 9, 2020, 5:30 AM Christian Heimes wrote:

...

On 09/10/2020 04.04, Ivan Pozdeev via Python-Dev wrote:

...

I don't see the point of requiring to "write an apology", especially *before a 12-month ban*. If they understand that their behavior is wrong, there's no need for a ban, at least not such a long one; if they don't, they clearly aren't going to write it, at least not now (they might later, after a few weeks or months, having cooled down and thought it over). So all it would achieve is public shaming AFAICS. Same issue with the threat of "zero tolerance policy" -- it's completely unnecessary and only serves to humiliate and alienate the recipient.

I have been the victim of Stefan's CoC violations on more than one occasion. He added me to nosy list of a ticket just to offend and humiliate me. For this reason I personally asked the SC to make a sincere apology a mandatory requirement for Stefan's reinstatement as a core dev.

I would have been fine with a private apology. However Stefan has also verbally attacked non-core contributors. In one case another core dev and I contacted the contribute in private to apologize and ensure that the contributor was not alienated by Stefan's attitude. Therefore it makes sense that the SC has requested a public, general apology.

Why are you more concerned with the reputation of a repeated offender and not with the feelings of multiple victims of harassment? As a victim of Stefan's behavior I feel that an apology is the first step to reconcile and rebuild trust.

At the risk of putting my nose in where it doesn't belong... I think that Ivan has some good general points. And i think that they could be distilled as this: if you are looking to correct bad behavior but allow a contributor to learn about proper behavior and then return to the community, the steps taken here seen counter-productive (1). I would add a second piece to that: If, on the other hand, the goal is to remove a toxic person from the community whoneeds to go through major personality shifting changes before they can be allowed back, then this may be appropriate (2).

For (1), what I'm getting from Ivan's post is that these measures are at a level that few (if any) people would be willing to fulfill them and then come back to be a non-bitter contributor. When the requirements are too costly for the violator to pay, they won't be able to learn and then pay those costs until they can disavow their former selves. "i'm sorry i acted like that; i was a *different person* back then. I'm sorry that *past me* felt the need to hurt you."

I would think that in general, not necessarily this specific case, the steering committee would want to try taking steps to get people to learn proper behavior first and only resort to something which amounts to a de facto permanent ban when it becomes apparent that the person has to go through some major personality changes before their behavior will change.

For (2), the steering committee is charged with protecting the community at large. A toxic person can cause great havoc by themselves and set the tone of a community such that other people feel that engaging in bad behavior is the proper thing to do in this community. With that in mind, at some point, this kind of action has to be on the table. It is great that pep-13 lists banning as a possibility so that people know where their actions can lead.

One thing i would suggest, though, is documenting and, in general, following a sequence of progressively more strict interventions by the steering committee. I think that just as it is harmful to the community to let bad behavior slide, it is also harmful to the community to not know that the steering committee's enforcement is in measured steps which will telegraph the committee's intentions and the member's responsibilities well in advance.

Hi Toshio, Thanks for sharing your thoughts with us in such a constructive manner. I appreciate it. Others on the Steering Council have done a good job of covering this particular situation. All I will add to their comments is that we spent many, many hours during our weekly meetings and via email and have tried to be respectful and thoughtful in our decisions. As for the additional information that you seek about process and progressive actions, these two links, particularly the second, give more details: - https://devguide.python.org/#code-of-conduct - https://www.python.org/psf/conduct/enforcement/ Thanks, Carol

This specific case may already have been out of hand by the time it came to the committee, the steering committee is relatively new and problems could have festered before they formed and started governing, but a new member of the community should know that if they step out of line, the committee will make it apparent to them what the expectations are and whether their ongoing behavior is putting them onto a disciplinary track well before that discipline gets to the point of a one year ban and a public apology.

Thanks for reading, -Toshio

...

_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/IDFQDRHR... Code of Conduct: http://python.org/psf/codeofconduct/

Hi, Le ven. 9 oct. 2020 à 21:02, Brett Cannon a écrit :

Another way to look at this is to realize that Stefan's behaviour may have scared off people who would have been willing to contribute to the decimal module. As Christian pointed out, there is already one instance of a contributor who he felt needed to be followed up with to make sure they were okay. As much as we know they could have become a major contributor to 'decimal' and this specific concern wouldn't even exist.

I dislike using Stefan as an example, but it seems like some people don't understand the Steering Council decision. I hope that my email will give a little bit more context. I don't want to discuss technical changes, but more share my feedback on a specific behavior. The intent of the Steering Council is to no longer tolerate specific behaviors, rather than to ban arbitrary people. I would like to share my own experience with the decimal module over the last years. In short, I learnt the hard way to never attempt to modify it (missing stair, see below) and I consider that it's an issue (behavior which should no longer be tolerated in Python). -- Multiple times, I wrote large PRs modifying tons of random files at once to replace one pattern with another. For example, to use a new faster C API. When one of my PR modified the decimal module, Stefan always asked me to revert my changes on this specific module. Honestly, I didn't even notice that the decimal module was modified, since I ran an automated command on the whole Python code base. The decimal module was always special and had special rules. Stefan was not helpful in getting my changes merged, but asked me for extra work to always exclude the decimal module from such "refactoring" PR. Once, I wrote a decimal bugfix for a specific Unicode issue related to the locale encoding for numbers. I wrote a test to prove that the current code fails and that it just works with my change. I did all the work (bugfix, manual test) but Stefan rejected my PR, considering that it's worth it to fix this bug (don't support such locale configuration). He used a third party test suite as a justification, but even when I asked, he didn't explain to me how to get it. That sounds unfair for people who want to contribute (to not have all development tooling available). I also wrote an optimization to speedup some decimal functions and methods by using the new METH_FASTCALL calling convention. Stefan also rejected my optimization, even if I proved that it makes decimal faster. I don't recall the details, but the reason was something about having the same code base in all Python branches. I didn't understand this rationale. Most stdlib modules subtle differences between each Python branch, to get new features, to use new Python features, etc. I never tried to argue with Stefan to get my changes merged. I like the decimal module, it's great, but it's not really my priority. Also, when I saw how Stefan replied to other people on other issues, I didn't want to go through similar bad interactions. At some point, I decided that Stefan is a missing stair, someone that I must avoid whenever I can: https://en.wikipedia.org/wiki/Missing_stair Stefan wants to work alone, don't attempt to touch his code base. Well, some people were more lucky than me and got their changed into the decimal module. I was never comfortable with the fact that other contributors must also avoid Stefan (missing stair) and so don't attempt to touch the decimal module. I would prefer greater collaboration on a stdlib module, because we have to distribute the maintenance to make Python sustainable. We must increase the bus factor: a bus factor of 1 is really dangerous. By the way, don't think about the bus factor as death, but more about people getting bored, tired/burned out, have family or any other personal issue. It's common that core developers suddenly stop contributing to Python without any warning and without training someone to continue the maintenance of the code they were taking care of. -- Stefan made the decimal module 100x faster in Python 3 which is amazing! He did a great job to maintain the code for newer compilers and platforms. He also fixed a bunch of bugs over the last years. Obviously, the steering council took in account the risk of losing a maintainer in their decision. There is nothing wrong with Stefan, the problem is only a specific behavior ("gatekeeper"). As Brett explained in another email, Stefan will be allowed to contribute again in one year as anyone, but being promoted as a core developer requires a special condition for him. Taking the decision of the ban was really hard and was really unpleasant (at least to me). It used a large part of our 1-hour weekly meeting for the last 2 months. We could use this time for other topics, but the steering council considers that the code of conduct is a priority. I am really proud of being part of the first steering council who took the first actions in reaction to Code of Conduct violations. Just for that, it was worth it to spend one hour per week to be part of this council ;-) The good news is that if core developers consider that the current Steering Council gone too far, there will be soon a new election for a new council! ;-) Victor (speaking for himself, not in the name of the Steering Council) -- Night gathers, and now my watch begins. It shall not end until my death.

On Sat, Oct 10, 2020 at 10:42 AM Jeff Allen wrote:

On 10/10/2020 00:56, Brett Cannon wrote:

On Fri, Oct 9, 2020 at 2:55 PM Toshio Kuratomi wrote:

...

One thing i would suggest, though, is documenting and, in general, following a sequence of progressively more strict interventions by the steering committee. I think that just as it is harmful to the community to let bad behavior slide, it is also harmful to the community to not know that the steering committee's enforcement is in measured steps which will telegraph the committee's intentions and the member's responsibilities well in advance.

Documenting exact steps is really hard when it comes to a Code of Conduct. Every case is unique and so rigid rules don't typically work well, e.g. requiring everyone to get a warning first would mean I could [...] way more and still be here without technical ramifications because we said, "you always get a warning first".

This is so painful I'm reluctant to add to the pile, so I'll be succinct (at risk of sounding brusque). Personally I find it a weak argument that the SC should not codify a system of warnings because some cases go bad so quickly that you have to act immediately. This may be necessary for drive-by trolls with a point to make. It would be rare in anyone with significant standing in the PSF. Anyway, you can have both.

I realise that core developer status is not employment, but I think there is a model worth considering in this: https://www.gov.uk/dismiss-staff/dismissals-on-capability-or-conduct-grounds... . This is guidance, not law over here, but an employment tribunal would take it as a definition of reasonable, so most decent employers adopt it as a policy.

I have been asked personally and privately multiple times over the years to step in and mediate conduct issues with Stefan over the years. Tack on a Conduct WG warning from just earlier this year and the multiple incidents subsequently and that's how I at least reached my decision that this was a reasonable approach to take.

Sounds like you were doing roughly as Toshio recommends anyway (the decent thing as I'd expect), but maybe explicit is better?

Jeff Allen

Thanks for sharing your thoughts and experience. The Python Software Foundation Code of Conduct Working Group Enforcement Procedures, https://www.python.org/psf/conduct/enforcement/ , provides explicit steps that are taken as well as the possibilities for behavior modification and also consequences. This document also outlines the process for proposing changes in the "Changes to Code of Conduct" section. While I am not an expert in UK employee law, the linked document includes the following wording:

You should include examples of what you consider to be misconduct in your disciplinary rules. Different disciplinary procedures are appropriate for different circumstances.

These concepts are reflected in Python's process. Carol

Ivan Pozdeev via Python-Dev writes:

Possessive and obstructive behavior like Victor describes below is incompatible with the bazaar model of development (=a model where the dev team accepts contributions from a wide range of people).

True, but Python *modules* have frequently followed a not-exactly- benevolent dictator model.[1] As mentioned by several contributors (including some who have expressed adverse opinions on the behavior in this case), the Decimal module is composed of extremely high-quality code, which has also been revised to provide a huge performance enhancement. Purely obstructive behavior is IMO relatively easy to identify, but it can be quite difficult to distinguish a very high quality standard from possessiveness. For the team members and occasional contributors, it can be very satisfying to clear a high bar after much effort. (But then, I have a PhD so I may not be a good person to testify on this.) Within modules, I think there is plenty of room for a wide variety of attitudes toward quality of code, especially given the branching capability of our VCS: from "move fast and break things" (and fix them even faster) to "every commit should be release-candidate-ready". (In some cases, such as the interpreter itself, the SC will want to mandate a level of QA, and of course any such standard will vary by branch and over the release cycle; that kind of situation is included, just not project-wide.)

As a result, both sides lose: users don't get the features/bugfixes that they want (since their contributions are being rejected for no good reason), maintainers don't get contributions (since their requirements are unreasonable or outright impossible to meet), both sides waste a lot of time unproductively in the process.

Sure, but there are also cases where extremely high standards lead to a small, tight-knit, and highly productive team. As a general policy, I hope the Steering Council will lean hard in the direction of inclusiveness, but by the same token we can include a few teams that choose to impose extremist standards on *themselves*. Of course, giving the benefit of doubt to the Decimal maintainer, sometimes extreme quality demands will conflict with project-wide efforts such as Victor's refactorings. I've dealt with such refactorings in the past: they can be a real PITA to other developers as the code they're working with changes out from under them. As Victor describes his work, it was worthwhile in terms of performance improvement, of very high quality in terms of regression testing for the particularly demanding Decimal module, and (I guess) not touching on the internals of the Decimal module (ie, the changes seem to be in boilerplate code for interfacing with the core code). In such cases it's not obvious where the burden of resolving the conflict *should* fall: with the "outsider" mucking around in "everybody else's" code, or with the individual maintainers, to keep their code up with best practices in the project. I don't see a general principle here. I think that when the parties involved don't negotiate a settlement themselves, this decision needs to be made on a case by case basis.

For a testimony from someone with more experience at maintaining than me, see e.g. http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s03.... and r > http://www.catb.org/~esr/writings/cathedral-bazaar/homesteading/ar01s11.html .

I don't really trust Eric on these issues. He has a very spotty history, himself, and in personal interactions I've seen him to be both quite open to personal criticism and rather hypocritical (in the literal sense of not thinking much about it and just accepting the natural human feeling that "I'm a good guy, I'm probably not wrong!") And in fact, both of those selections expose internal contradictions of the models ESR espouses. I agree, those are seminal models, but as the word "seminal" suggests, they needed a lot of development.

AFAICS, Python uses the bazaar model as its development principle. As such, Stefan could be suspended even earlier, at one of the instances that Victor described, -- for sabotaging the project.

In this case, I tend to agree with you *in theory* based on what has been stated (and mindful of the fact that Stefan has said very little), but I could only advocate action if I knew *much* more of the facts. But I don't see how this could possibly be usefully enunciated as policy. It's too fact-dependent.

On 10.10.2020 16:46, Victor Stinner wrote:

...

I was never comfortable with the fact that other contributors must also avoid Stefan (missing stair) and so don't attempt to touch the decimal module. I would prefer greater collaboration on a stdlib module, because we have to distribute the maintenance to make Python sustainable.

I think "comfortable" is an excellent word here. I don't think that the Steering Council can make sufficiently detailed rules to avoid all case-by-case decisions, and sometimes difficult cases are going to be decided by minimizing their discomfort. As long as they recognize that's what they're doing, and don't claim a provable decision from first principles, I'm happy with that. (Speaking for nobody but myself.)

...

The good news is that if core developers consider that the current Steering Council gone too far, there will be soon a new election for a new council! ;-)

I don't think that's good news, to be honest. It's necessary, and I hope that there is some turnover.[2] But overall continuity is necessary, even if some of it's bad. In my opinion, the Steering Council should aim to add a very few good practices and delete or improve a few bad ones each cycle.[3] We're starting from a pretty good status quo ante -- don't mess with success! Footnotes: [1] AFAIK the maintainers involved are good people and well-liked, but frequently they'd disappear for years and wouldn't appoint a deputy, even temporarily. [2] Mostly because this can be emotionally distressing work for the Council members. Nobody should have to make decisions like this one very often. [3] For people it's the opposite, of course. Adding should be many good ones, and suspending/banning as few as possible.

the problem is only a specific behavior ("gatekeeper").

I'm (obviously) not on the SC, but I have to strongly disagree with you here -- there is nothing inherently wrong with being a gatekeeper, nor is there anything in the CoC about it. A gatekeeper can help ensure high-quality code, can provide a direction for a module, can keep a module from bloating, etc. The issue that I saw with Stefan was his treatment of others: some of his actions on b.p.o. were cruel and hateful, and some of his messages were demeaning and spiteful. If his behavior in person is anything close to his online persona he would definitely be a missing stair for me.

Victor (speaking for himself, not in the name of the Steering Council)

Thank you for clarifying. Also, my thanks to the Steering Council - personnel problems are never fun nor easy to deal with, and I appreciate you and them for making it a priority. -- ~Ethan~

On Tue, Oct 13, 2020 at 11:17:33AM +0100, Steve Holden wrote:

Full marks to the SC for transparency. That's a healthy sign that the community acknowledges its disciplinary processes must also be open to scrutiny, and rather better than dealing with matters in a Star Council.

The SC didn't say anything until Antoine posted an open letter from Stefan to the list. There is tension between the requirements of openness and privacy, and I don't have a good answer for where the balance should be. But it seems to me that giving "full marks for transparency" for a decision made behind closed doors that we only found about about because one of the parties was able to announce their ban via a third party is a remarkably soft grade. Steve

Reading through this thread and the linked comment chains was very educational. While I'm not involved enough to form an educated opinion, it's good to see that the wheels of python org are moving. That being said, I think that "dear stefan" email could have been written better. Also +1 on "not punitive" rule from wikipedia, cheers, Ivan! On Tue, 13 Oct 2020 at 21:05, Thomas Wouters wrote:

On Tue, Oct 13, 2020 at 1:32 PM Steven D'Aprano wrote:

...

On Tue, Oct 13, 2020 at 11:17:33AM +0100, Steve Holden wrote:

...

Full marks to the SC for transparency. That's a healthy sign that the community acknowledges its disciplinary processes must also be open to scrutiny, and rather better than dealing with matters in a Star Council.

The SC didn't say anything until Antoine posted an open letter from Stefan to the list.

We didn't say anything because, as I mentioned, we wanted to discuss the matter with Stefan before we did so. Also, as I mentioned, we had a back-and-forth with Stefan, and were not aware he had already decided not to comply with our requests or the Code of Conduct. Had he let us know, we would've posted pretty much the same information a few days later.

...

There is tension between the requirements of openness and privacy, and I don't have a good answer for where the balance should be. But it seems to me that giving "full marks for transparency" for a decision made behind closed doors that we only found about about because one of the parties was able to announce their ban via a third party is a remarkably soft grade.

The SC had already discussed how public to be about this, and we were always going to publish our decision as well as our initial correspondence to Stefan. Posting his replies is not up to us, and posting our replies to him without that context feels unfair and inappropriate. However, the Conduct WG was copied on all the correspondence. This was not backroom justice.

The SC does have to balance openness and privacy, and also fairness, the health of the code base, the health of the community, personal feelings of individual contributors, the perceptions our actions and decisions and silence create for the individuals involved, the other core developers, and the Python community at large. We're also still figuring out the process and standards we want to set for this kind of thing, because it is fairly new to the core developer community.

-- Thomas Wouters

Hi! I'm an email virus! Think twice before sending your email to help me spread! _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/4FXU6ZZR... Code of Conduct: http://python.org/psf/codeofconduct/