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 <br...@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-le...@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/
