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.