and I'm sorry but a project being 'open source' doesn't mean that everyone can or should contribute, not all contributions are good or helpful and if you have a certain standard in mind for your software you have to filter contributions.
- an open source project which you advertise as collaborative open source
- a personal vision for what you want in your project
- and hence, a secret list of requests you will turn down
Then frequently people might spend 10, 20, 30, 60 minutes trying to do something with your project then writing up an issue. You then immediately shoot it down, because it doesn't match your vision, and that person gets burned.
If you have MIT license and no guidance on contribution, that's user error. But if your project has a PR workflow or has that "Imposter syndrome" line about contributions, well, maybe it's partly your fault.
I'm not saying all open source projects should have guidance. But perhaps all projects with a CONTRIBUTING.md and ISSUE_TEMPLATE.md really should have a clear list of features they will outright reject.
So if someone sends you a contribution that isn't good enough, you reject them with a "no", and that's it?
Sure, you can do that. A different project might expend some time teaching that contributor and being nice to them, until their PR can be merged. And then the contributor submits another one that's better, and then another one, and then before you realize it you have another full time maintainer that you can trust.
So when you say that if a contribution isn't good enough you reject it I say "Thank you", because that person will move on to a different open source project, which might be one of mine, and I'll be getting another contributor instead.
You might not think that the work required to attract a new full-time contributor is worth it. To me it is.