Comment by pasc1878
One issue here is that the main author has very limited resources. Thus can only support a small amount of code.
Your Pull Request makes the project larger and it needs to be maintained - so making the load on the original author larger. If it fixes a bug then it helps the original author and so can be accepted. So it is not closed contributions but rather it has a defined scope and we are not going let the project suffer from scope creep.
One example of this is a project written on Linux - it does run on macOS but not fully correctly. The original author just says I don't have access to a Mac so cannot support it. They are not being a bad person here just stating a fact. The answer here is that there is now a fork that does support macOS, hopefully correctly but I would not be surprised if there are bugs due too differences in the OS - the major ones have been made but I'll bet that a full code review has not been done over every line of code.
I understand these issues and project maintainers don’t owe random people a merge. But they do owe random people a little clarity about what should be expected as a potential contributor.
It’s not that much to ask. Realistically as programmers we should probably solve these problems with data and not waste anyone’s time. If your supposedly open project has never merged a pr by a non-member or a person without a looong history of hanging out on the projects social periphery, then non-members should be warned when they submit a PR that this is the case. Saves 2 weeks of fake requests for tests/documentation/justifications when the real issue is a steering committee that prefers insiders-only. And again, that’s fine, it’s just the missing transparency that’s the real problem.
And yeah, even clearly needed bug fixes can still be in this category, it doesn’t take a major feature that’s going to be a maintenance burden. 3 weeks (or years) of discussion arguing the bug is not a bug, followed by the users saying it’s a bug, and then maintainers asking for changes/docs/tests and then when that’s all in place, maintainers pivot to suggesting it needs to be an extension/plugin or whatever. In some ecosystems this kind of thing is more common than elsewhere.. but if you’ve never seen this count yourself lucky. Naming projects is tempting here but in the end it’s unpaid work that’s a passion project for an army of volunteers. But the volunteers are still just dumb monkeys that really enjoy dumb hierarchies, so what can you do..