Hacker News Reader

Comment by taleinat | Hacker News Reader

(I'm a Python core dev, speaking for myself.)

Python is almost entirely developed and maintained by volunteers. The increasing backlog of issues and PRs is recognized as a problem.

Thanks to a generous donation, the PSF has recently begun employing one "developer in residence", Łukasz Langa. He is specifically tasked with tackling this backlog, and has been doing a mighty good job so far.

Still, with over 1,000 open PRs and many times more open issues, we (the Python devs) could use more helping hands. For example, anyone can confirm that bugs reproduce, review PRs, or test fixes, and those are all meaningful help (when done thoughtfully and thoroughly.)

I, and most core devs, volunteer happily and ask for nothing in return. If you think the situation outlined in the parent post isn't great and begs improvement, you're welcome to help!

View on HN

Don't get me wrong I'm a huge FOSS fan and proponent, but I think your post illustrates very clearly what is wrong with the state of OSS today. We are talking a language like python that probably underpins profits on the order of tens of billions a year and is largely maintained by volunteers in their free time and the foundation can hire one dev! Somehow companies managed to outsource all the work to "the public" while keeping the profits for themselves.

That's the world we live in. Many banks have custom forks of Python and various other tools but they don't care to release their code. Illegal? Sure, but they're banks, they're kind of exempt as companies are.

A while ago someone posted here a post of Cray/HPE complaining to a bunch of volunteers on the GCC Fortran project that F2018 support was incomplete. The GCC team fully acknowledges its incompleteness, and knows that it is in fact, incomplete. It is not recommended for production applications. There are about 10 other compilers, some by companies such as NVIDIA and Intel, which would work perfectly fine and which have full F2018 support. But instead of using any of these, or seeing as the one complaining is on the committee that created the F2018 specification, going out and fixing it yourself, they complained to like 6 people because their government project was falling behind because of their inability to even comprehend that some group of internet communists will not do free work for them.

Literally idiotic. You're a representative one of the world's largest companies when it comes to this kind of stuff and perhaps one of the most knowledgeable people on Fortran alive. Go fix it or stop using beta products by internet communists for government contracts.

I think the entire point of this post is that people do NOT feel welcome to help, and it is being suggested that their experiences are one reason there is such an unmanageable backlog.

I agree with everything you say, and alluded to much of it in the parent post. I myself also volunteer happily on a number of projects, and attempt to keep up with similar deluges on those projects.

For someone like myself who is not already a core Python maintainer, how would you recommend making improvements to things like the Python documentation if not by raising pull requests?

For a specific doc fix, a PR is indeed the way to go. If it's not a simple fix, creating an issue on the tracker may also be called for. Doing so does help and is appreciated, even if it sometimes takes a long time to be addressed by a core dev.

Otherwise, one could help in ways like I mentioned previously: reading existing issues, checking if they are still relevant and commenting accordingly, reviewing PRs and patches, etc.

> For a specific doc fix, a PR is indeed the way to go. If it's not a simple fix, creating an issue on the tracker may also be called for.

That is precisely what I did. As noted, there has been no indication (by activity on the issue or PR) that having filed these helped or is appreciated. Hence discouragement.

It is one of the hard lessons of open source maintainership that, without providing feedback to contributors, there is no demonstration of the project's appreciation. Therefore new contributors will (correctly!) conclude that the project does not appreciate these efforts.

I think the key point that you are making is that projects which need more help should place higher priorities on working through PR and issue backlogs as those are a primary way to taking people who are willing to help and converting them into more dedicated and integrated maintainers. Letting those backlogs languish because you don't have enough volunteers becomes a self a reinforcing cycle that becomes harder and harder to break out of.

I'd love if someone could solve the problem with package management in Python. Make Pip Great Again - faster and more stable than poetry. Something like a kickstarter campaign would work. I'd give you money.

Reply on news.ycombinator.com