[Python-Dev] Re: [python-committers] Resignation from Stefan Krah

2020-10-10 Thread Victor Stinner 
Hi,

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

I dislike using Stefan as an example, but it seems like some people
don't understand the Steering Council decision. I hope that my email
will give a little bit more context. I don't want to discuss technical
changes, but more share my feedback on a specific behavior. The intent
of the Steering Council is to no longer tolerate specific behaviors,
rather than to ban arbitrary people.

I would like to share my own experience with the decimal module over
the last years. In short, I learnt the hard way to never attempt to
modify it (missing stair, see below) and I consider that it's an issue
(behavior which should no longer be tolerated in Python).

--

Multiple times, I wrote large PRs modifying tons of random files at
once to replace one pattern with another. For example, to use a new
faster C API. When one of my PR modified the decimal module, Stefan
always asked me to revert my changes on this specific module.
Honestly, I didn't even notice that the decimal module was modified,
since I ran an automated command on the whole Python code base.

The decimal module was always special and had special rules. Stefan
was not helpful in getting my changes merged, but asked me for extra
work to always exclude the decimal module from such "refactoring" PR.

Once, I wrote a decimal bugfix for a specific Unicode issue related to
the locale encoding for numbers. I wrote a test to prove that the
current code fails and that it just works with my change. I did all
the work (bugfix, manual test) but Stefan rejected my PR, considering
that it's worth it to fix this bug (don't support such locale
configuration). He used a third party test suite as a justification,
but even when I asked, he didn't explain to me how to get it. That
sounds unfair for people who want to contribute (to not have all
development tooling available).

I also wrote an optimization to speedup some decimal functions and
methods by using the new METH_FASTCALL calling convention. Stefan also
rejected my optimization, even if I proved that it makes decimal
faster. I don't recall the details, but the reason was something about
having the same code base in all Python branches. I didn't understand
this rationale. Most stdlib modules subtle differences between each
Python branch, to get new features, to use new Python features, etc.

I never tried to argue with Stefan to get my changes merged. I like
the decimal module, it's great, but it's not really my priority. Also,
when I saw how Stefan replied to other people on other issues, I
didn't want to go through similar bad interactions.

At some point, I decided that Stefan is a missing stair, someone that
I must avoid whenever I can:
https://en.wikipedia.org/wiki/Missing_stair

Stefan wants to work alone, don't attempt to touch his code base.
Well, some people were more lucky than me and got their changed into
the decimal module.

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

We must increase the bus factor: a bus factor of 1 is really
dangerous. By the way, don't think about the bus factor as death, but
more about people getting bored, tired/burned out, have family or any
other personal issue. It's common that core developers suddenly stop
contributing to Python without any warning and without training
someone to continue the maintenance of the code they were taking care
of.

--

Stefan made the decimal module 100x faster in Python 3 which is
amazing! He did a great job to maintain the code for newer compilers
and platforms. He also fixed a bunch of bugs over the last years.

Obviously, the steering council took in account the risk of losing a
maintainer in their decision. There is nothing wrong with Stefan, the
problem is only a specific behavior ("gatekeeper"). As Brett explained
in another email, Stefan will be allowed to contribute again in one
year as anyone, but being promoted as a core developer requires a
special condition for him.

Taking the decision of the ban was really hard and was really
unpleasant (at least to me). It used a large part of our 1-hour weekly
meeting for the last 2 months. We could use this time for other
topics, but the steering council considers that the code of conduct is
a priority.

I am really proud of being part of the first steering council who took
the

[Python-Dev] Re: [python-committers] Resignation from Stefan Krah

2020-10-10 Thread Jeff Allen 

On 10/10/2020 00:56, Brett Cannon wrote:
On Fri, Oct 9, 2020 at 2:55 PM Toshio Kuratomi > wrote:



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


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


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


I realise that core developer status is not employment, but I think 
there is a model worth considering in this: 
https://www.gov.uk/dismiss-staff/dismissals-on-capability-or-conduct-grounds#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

___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/FBUJDYPYTCTJDZUQTY2WX3PW4OEZ2XZR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [python-committers] Resignation from Stefan Krah

2020-10-10 Thread Carol Willing 
On Sat, Oct 10, 2020 at 10:42 AM Jeff Allen  wrote:

> On 10/10/2020 00:56, Brett Cannon wrote:
>
> On Fri, Oct 9, 2020 at 2:55 PM Toshio Kuratomi  wrote:
>
>>
>> One thing i would suggest, though, is documenting and, in general,
>> following a sequence of progressively more strict interventions by the
>> steering committee.  I think that just as it is harmful to the community to
>> let bad behavior slide, it is also harmful to the community to not know
>> that the steering committee's enforcement is in measured steps which will
>> telegraph the committee's intentions and the member's responsibilities well
>> in advance.
>>
>
> Documenting exact steps is really hard when it comes to a Code of Conduct.
> Every case is unique and so rigid rules don't typically work well, e.g.
> requiring everyone to get a warning first would mean I could [...] way more
> and still be here without technical ramifications because we said, "you
> always get a warning first".
>
> This is so painful I'm reluctant to add to the pile, so I'll be succinct
> (at risk of sounding brusque). Personally I find it a weak argument that
> the SC should not codify a system of warnings because some cases go bad so
> quickly that you have to act immediately. This may be necessary for
> drive-by trolls with a point to make. It would be rare in anyone with
> significant standing in the PSF. Anyway, you can have both.
>
> I realise that core developer status is not employment, but I think there
> is a model worth considering in this:
> https://www.gov.uk/dismiss-staff/dismissals-on-capability-or-conduct-grounds#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
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/FIYLQT7QDTXRCSAOSDW7OW3YCSS3TKQ4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [python-committers] Resignation from Stefan Krah

2020-10-10 Thread Ivan Pozdeev via Python-Dev 
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  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