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