Mailing List Archive

Sorry to see you go, Stefan. You will be missed. -- H

On Wed, 7 Oct 2020 at 14:50, Antoine Pitrou <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
> 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/ZIAN7ERZNF4ZE2B2SLYNRPVNERNACG5A/
> 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=0xFEBAD7FFD041BBA1>Sent
from my mobile device
Envoye de mon portable

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
* 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 <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
> 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
> To unsubscribe send an email to 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/ZIAN7ERZNF4ZE2B2SLYNRPVNERNACG5A/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>


--
Thomas Wouters <thomas@python.org>

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

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 <antoine@python.org <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/ZIAN7ERZNF4ZE2B2SLYNRPVNERNACG5A/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
>
>
> --
> Thomas Wouters <thomas@python.org <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/BSFWGLR45PKP6CK3LW2ZHVPYFCXWNFBI/
> Code of Conduct: http://python.org/psf/codeofconduct/
> --
> Regards,
> Ivan

Le ven. 9 oct. 2020 à 04:14, Ivan Pozdeev via Python-Dev
<python-dev@python.org> a écrit :
> 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).

The question was to ban or no, there is a 12-month ban in any case:

"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."

Victor
--
Night gathers, and now my watch begins. It shall not end until my death.
_______________________________________________
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/VP6EBYQ5L666SGFU7Y2BRRM52ENFCPA5/
Code of Conduct: http://python.org/psf/codeofconduct/

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
_______________________________________________
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/LGYATAHYU2EL5BH4NPKKZQDIIGEVNXQL/
Code of Conduct: http://python.org/psf/codeofconduct/

On Fri, 9 Oct 2020 05:04:55 +0300
Ivan Pozdeev via Python-Dev <python-dev@python.org> 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.

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/DKNXYE3LMZQUDZEIMELNZPBQMWSFPOXF/
Code of Conduct: http://python.org/psf/codeofconduct/

On 09/10/2020 15.48, Antoine Pitrou wrote:
> On Fri, 9 Oct 2020 05:04:55 +0300
> Ivan Pozdeev via Python-Dev <python-dev@python.org> 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.
_______________________________________________
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/5KTGHFOGDYBUBD6JAC3A7QELDSIZYDLP/
Code of Conduct: http://python.org/psf/codeofconduct/

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 <python-dev@python.org> 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 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?

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/5WX63I23WZ4ZBJALWDA3VBSGV3J5KLM5/
Code of Conduct: http://python.org/psf/codeofconduct/

----- Original Message -----
> From: "Antoine Pitrou" <antoine@python.org>
> 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 <python-dev@python.org> 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/5WX63I23WZ4ZBJALWDA3VBSGV3J5KLM5/
> 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/6QCFOVUS5PIPXWWHNXPWB26EPM26UHAR/
Code of Conduct: http://python.org/psf/codeofconduct/

On Fri, Oct 9, 2020 at 10:25 AM Charalampos Stratakis <cstratak@redhat.com>
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.

--
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.

On Fri, Oct 9, 2020 at 7:23 AM Charalampos Stratakis <cstratak@redhat.com>
wrote:

>
>
> ----- Original Message -----
> > From: "Antoine Pitrou" <antoine@python.org>
> > 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 <python-dev@python.org> 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.
>

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/5WX63I23WZ4ZBJALWDA3VBSGV3J5KLM5/
> > 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/6QCFOVUS5PIPXWWHNXPWB26EPM26UHAR/
> Code of Conduct: http://python.org/psf/codeofconduct/
>

On Fri, Oct 9, 2020 at 5:34 AM Christian Heimes <christian@python.org>
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.
>

I think another way to view it is an apology shows intent to improve. I'm
not sure how universal it is, but in North America it's common to teach
kids that the first thing they do when they have been mean to someone is to
apologize to demonstrate remorse and to reinforce that what the child did
was wrong. In this instance there were multiple people that Stefan was mean
to and with enough severity to warrant an apology.

I would also argue that the fact that all of these acts against others
occurred publicly suggests that the apology should also be public.

On Fri, Oct 9, 2020 at 12:05 PM David Mertz <mertz@gnosis.cx> wrote:

> On Fri, Oct 9, 2020 at 10:25 AM Charalampos Stratakis <cstratak@redhat.com>
> 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/2UQX46YPBBMV4EUCEVI4TNNZQLQHZDI6/
> Code of Conduct: http://python.org/psf/codeofconduct/
>

09.10.20 16:48, Antoine Pitrou ????:
> Also, we now have an unmaintained module
> (_decimal) requiring specific competence.

It is not so bad. Due to high quality of the module there were not much
changes in it in recent years, and many of them were cosmetic. We also
have other Decimal experts.
_______________________________________________
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/CCITUQVXSEQELH3ZAQTQTHTWGBVVSASD/
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
_______________________________________________
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/XPZI4CWHJ2FB4BLUIZ54II6WLHZQKUV3/
Code of Conduct: http://python.org/psf/codeofconduct/

On Fri, Oct 9, 2020, 5:30 AM Christian Heimes <christian@python.org> 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.

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

>

On Fri, Oct 9, 2020 at 2:50 PM Toshio Kuratomi <a.badger@gmail.com> wrote:

>
>
> On Fri, Oct 9, 2020, 5:30 AM Christian Heimes <christian@python.org>
> 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/IDFQDRHRA2JJ6OJAK2265UHCBEI45PIM/
> Code of Conduct: http://python.org/psf/codeofconduct/
>

On Fri, Oct 9, 2020 at 2:55 PM Toshio Kuratomi <a.badger@gmail.com> wrote:

>
>
> On Fri, Oct 9, 2020, 5:30 AM Christian Heimes <christian@python.org>
> 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."
>

And Stefan can still do that. As stated in the email we sent him, he can
still apply to become a core dev again after one year just like anyone else
out there. But I also expect that unless he has demonstrated remorse that
other core developers will not vote to bring him back in, nor would the SC
allow the reinstatement (which the SC is allowed via PEP 13).

But a key thing here is there are human beings who were hurt by what Stefan
did as well. It's a balance between treating Stefan justly but also getting
closure for the victims. And I think asking those who were on the receiving
end of mean behaviour to wait a whole year for a sense of closure is not
fair, hence why I supported asking for an apology upfront.


> 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.
>

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 do everything
Stefan did and way more and still be here without technical ramifications
because we said, "you always get a warning first". There's a reason why the
PSF CoC is structured as it is: those that are tasked with dealing with
these sort of (very stressful) situations need flexibility to address it in
an appropriate manner to that specific example. In other words I personally
have no plans to introduce explicit guidelines for the SC around conduct.
My personal guideline is: don't be mean, and if you are then hopefully you
trust me to be fair for your unique situation while I serve on the SC.

And what this means is that you should vote for SC members based on how you
think they will respond to these sorts of situations as they will be the
ones tasked with dealing with conduct issues. For instance, if you don't
like how this was handled or trust me in how I will suggest handling future
conduct issues then you shouldn't vote for me in the next SC election (and
which I won't take personally as I know this is a very subjective thing).


>
> 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.
>

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 with Stefan.

Hi,

Le ven. 9 oct. 2020 à 21:02, Brett Cannon <brett@python.org> 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.
_______________________________________________
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/2JNRUSNYZT6W3S3BGSRZBL4GPJBBS3KM/
Code of Conduct: http://python.org/psf/codeofconduct/

On 10/10/2020 00:56, Brett Cannon wrote:
> On Fri, Oct 9, 2020 at 2:55 PM Toshio Kuratomi <a.badger@gmail.com
> <mailto:a.badger@gmail.com>> 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#disciplinary-procedures
. 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

On Sat, Oct 10, 2020 at 10:42 AM Jeff Allen <ja.py@farowl.co.uk> wrote:

> On 10/10/2020 00:56, Brett Cannon wrote:
>
> On Fri, Oct 9, 2020 at 2:55 PM Toshio Kuratomi <a.badger@gmail.com> 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#disciplinary-procedures
> . 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

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).

I've dealt with projects that exert this kind of attitude (Tcl and Git for Windows are the latest examples), and it's invariably been
miserable: maintainers that do this typically deem everyone else unworthy to get their code into the project, either at all or unless they
do things exactly as the maintainer wants to -- thus effectively requiring one to read their mind and ignoring anything that's not on their
mind. 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.

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.html and
http://www.catb.org/~esr/writings/cathedral-bazaar/homesteading/ar01s11.html .

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.

On 10.10.2020 16:46, Victor Stinner wrote:
> Hi,
>
> Le ven. 9 oct. 2020 à 21:02, Brett Cannon <brett@python.org> 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)
> --
> Regards,
> Ivan
_______________________________________________
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/JOWK3EUEVA7FNI7PIMUBTFDL7WJWQ2R3/
Code of Conduct: http://python.org/psf/codeofconduct/

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.html 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.
_______________________________________________
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/Y7MKERB5ULTR56F7ZZCYBLCG3DQJHS2V/
Code of Conduct: http://python.org/psf/codeofconduct/

On Sun, 11 Oct 2020 16:05:07 +0900
"Stephen J. Turnbull" <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
> 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]

Or even Python itself, putting aside "benevolent" which is a subjective
judgement affected by selection bias: those who don't approve of a
"B"DFL's governance tend to leave the project, so the remainers
generally find him quite benevolent.

Bazaar vs. cathedral is really a false dichotomy, there are lots of
concrete variations between the two but also on other dimensions. In
every project, you have insiders who act as gatekeepers wrt. external
contributions (can be a singular insider, too).

(also I would take Eric Raymond's writings with a pinch of salt,
personally; they were written in the context of an ideological battle
between free software and open source advocates, and criticizing the
"cathedral" model was also a way of getting at the GNU project)

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/JBWW2VT3K4YPZ2U2OS2C35DG2GIGZN4G/
Code of Conduct: http://python.org/psf/codeofconduct/

> 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~
_______________________________________________
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/WBNVFYQ2VFV53ZNUXEGELOAARDJ4L7AX/
Code of Conduct: http://python.org/psf/codeofconduct/

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.

Kind regards,
Steve


On Fri, Oct 9, 2020 at 12:10 AM Thomas Wouters <thomas@python.org> 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
> * 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 <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
>> 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
>> To unsubscribe send an email to 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/ZIAN7ERZNF4ZE2B2SLYNRPVNERNACG5A/
>> Code of Conduct: https://www.python.org/psf/codeofconduct/
>>
>
>
> --
> Thomas Wouters <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/BSFWGLR45PKP6CK3LW2ZHVPYFCXWNFBI/
> Code of Conduct: http://python.org/psf/codeofconduct/
>

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
_______________________________________________
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/IQZNTGMRGNWVHDGZVYKO4KXJ5TF4CO2E/
Code of Conduct: http://python.org/psf/codeofconduct/

On Tue, Oct 13, 2020 at 1:32 PM Steven D'Aprano <steve@pearwood.info> 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 <thomas@python.org>

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

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 <thomas@python.org> wrote:
>
>
>
> On Tue, Oct 13, 2020 at 1:32 PM Steven D'Aprano <steve@pearwood.info> 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 <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/4FXU6ZZRLZ6274QSEMXWDXZM6XTKH2W5/
> Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
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/JQQUTBRIGRUCBMDJI67AOQGEUXEIQWDE/
Code of Conduct: http://python.org/psf/codeofconduct/