Comment by photonthug
Comment by photonthug 2 months ago
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..
> 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.
Absolutely not, no.
A potential contributor can start by assessing the project. This can begin by politely asking the maintainer whether a particular patch will be accepted. Or, the contributor can examine the project history.
If the potential contributor receives no response, or sees no indication of a robust history of merging patches, then assume no patches will be merged. The code is there for the taking. The contributor is free to fork it and modify at will.
Rich Hickey said this best:
"As a user of something open source you are not thereby entitled to anything at all. You are not entitled to contribute. You are not entitled to features. You are not entitled to the attention of others. You are not entitled to having value attached to your complaints. You are not entitled to this explanation."
https://gist.github.com/richhickey/1563cddea1002958f96e7ba95...