Indeed, this should be another forum topic to not derail the discussion here.
Since there is no single central “OSM”, just a loose-ish collection of mostly individual projects, yes it is mostly up to the people who put up the effort operate those individual projects to decide what they are willing to integrate or change about them. If you want to see something changed, you need to do the work and that might have to go beyond just creating a fire and forget pull request if it’s a major overhaul. You might have to commit yourself long-term to the maintenance and operation of the project.
Not being good enough code or not complying with the code style seem like perfectly good reasons to not accept a pull request. Or are you implying that the developers/operators are just looking for made up reasons to deny changes?
Aside from ‘simply’ writing the code, part of the responsibility of anyone requesting a change or submitting patches to a project is to check if the proposed changes are
- a cultural and social fit for the project
- fall within the technological scope of the project and need to be implemented there and not somewhere else
- are functionally sound and well implemented
- are possible to sustain with the resources available to the project, both technological and social
- …
I’m pretty sure plenty of pull requests do not end up being integrated fall short on some of those measures.
You also seem pretty dismissive about the amount of work that goes into the day to day maintenance and operation of these projects and the amount of work that is required for reviewing pull requests. Calls to help out with those aspects of OSM projects mostly end up falling on deaf ears.