3 ms·

I really wish I could somehow push back on this with the python foundation, but I’m not sure how.

zahlman 2y ago
My personal plan is, essentially, to keep using Python while ignoring the PSF's existence, and pointing out (e.g. via blogging) technical faults with whatever new features are added (or faults that persist due to neglect). This applies not just to the core language and standard library, but also popular tools in the ecosystem - i.e. everything under the PyPA umbrella (https://github.com/pypa https://github.com/pypa) and popular tools and third-party libraries now maintained by the PSF (https://github.com/psf https://github.com/psf). Critique - whether technical or social - is vital for improvement. If their policies tend to exclude what they don't want to hear, say it somewhere else. I've seen quite a few people talk about forking or abandoning Python. I think both of these would be counterproductive. A boycott of the language can't really harm the PSF, certainly not financially. Any kind of e.g. deliberate nuisance use of PyPI - even if legal (I am not a lawyer; regardless I am definitely not advocating any such thing) -would impact on infrastructure sponsors like Fastly, not on the PSF directly. A fork, meanwhile, would be a monumental effort to accomplish very little; aside from the technical work, convincing others to switch would require building up trust on top of raising awareness of any PSF malfeasance. Of course, if you're already a PSF sponsor, you could just give up on that. I would encourage anyone who is in charge of a medium-sized OSS project to be proactive to prevent this kind of situation from arising in the future. Write "code of conduct" documents that reflect your values, so that nobody can say that you're missing a code of conduct. (Note that e.g. GitHub tooling special-cases files named "Code of Conduct.md" in the project root.) Form a foundation with a proper charter if you need to. If you see yourself as a BDFL, make that clear - and proactively prepare an exit plan that can leave things in the care of someone you can actually trust. Proactively consider any ideologies you can even vaguely imagine people trying to splice into your project's DNA (maybe you find some acceptable!) and form your arguments against them in advance (if applicable). Make sure that anyone who tries it gets told - as promptly as possible, and politely but firmly - to go suck a lemon. Be prepared to defend those decisions on social media, ideally by pointing at pre-written statements. Yes, that's a lot of work. So are unit tests and proper documentation. Entryists (of all stripes) generally operate by taking advantage of your kindness - but that kindness is essential to your existing community. Therefore, you must be prepared in advance to explain why kindness doesn't entail capitulating to their demands.

My personal plan is, essentially, to keep using Python while ignoring the PSF's existence, and pointing out (e.g. via blogging) technical faults with whatever new features are added (or faults that persist due to neglect). This applies not just to the core language and standard library, but also popular tools in the ecosystem - i.e. everything under the PyPA umbrella (https://github.com/pypa https://github.com/pypa) and popular tools and third-party libraries now maintained by the PSF (https://github.com/psf https://github.com/psf). Critique - whether technical or social - is vital for improvement. If their policies tend to exclude what they don't want to hear, say it somewhere else. I've seen quite a few people talk about forking or abandoning Python. I think both of these would be counterproductive. A boycott of the language can't really harm the PSF, certainly not financially. Any kind of e.g. deliberate nuisance use of PyPI - even if legal (I am not a lawyer; regardless I am definitely not advocating any such thing) -would impact on infrastructure sponsors like Fastly, not on the PSF directly. A fork, meanwhile, would be a monumental effort to accomplish very little; aside from the technical work, convincing others to switch would require building up trust on top of raising awareness of any PSF malfeasance. Of course, if you're already a PSF sponsor, you could just give up on that. I would encourage anyone who is in charge of a medium-sized OSS project to be proactive to prevent this kind of situation from arising in the future. Write "code of conduct" documents that reflect your values, so that nobody can say that you're missing a code of conduct. (Note that e.g. GitHub tooling special-cases files named "Code of Conduct.md" in the project root.) Form a foundation with a proper charter if you need to. If you see yourself as a BDFL, make that clear - and proactively prepare an exit plan that can leave things in the care of someone you can actually trust. Proactively consider any ideologies you can even vaguely imagine people trying to splice into your project's DNA (maybe you find some acceptable!) and form your arguments against them in advance (if applicable). Make sure that anyone who tries it gets told - as promptly as possible, and politely but firmly - to go suck a lemon. Be prepared to defend those decisions on social media, ideally by pointing at pre-written statements. Yes, that's a lot of work. So are unit tests and proper documentation. Entryists (of all stripes) generally operate by taking advantage of your kindness - but that kindness is essential to your existing community. Therefore, you must be prepared in advance to explain why kindness doesn't entail capitulating to their demands.