> I’ve submitted a handful of pull requests and I’ve already run into the classic “Your patch works and provides a feature some people might like, but I don’t like it, go away.”
This might be because they’re not interested in maintaining it for future iterations.
I've contributed PRs to several OSS projects, some have been merged, others have not. I'm fine with that.
The reason I open a PR is so that it becomes public.
Most of my PRs solve stuff that I wanted to solve. For example at some point I added simple math expression evaluation in the Start menu of Linux Mint. It worked, I use it in my computer and I published it as a PR. I Think it was rejected because of so e bureaucracy. It's OK. It's there if someone finds it useful, I do t care doing bureaucracy, but I understand why they would want that.
Normally the larger the project the more "bureaucratically painful" it is to have a PR accepted. In small obe person projects, .y experience has been that original devs are surprised and happy to know that someone used their code s d is bui5on top of it.
Absolutely! I'm the maintainer of a small Open Source project [1] and this phrase makes me tickle.
I totally get it that a maintainer doesn't want to merge some code, even if it's totally working. Is the new feature a niche case, or has if a wide audience? Is it aligned with the project goal/philosophy? Will it be easy to maintain/evolve/debug? Does it add unnecessary/unwanted dependencies? At the end of the day, the maintainer will be the person that have to work/support with this code.
Please keep in mind that if you've spent an hour on a project, maintainers have have certainly spent hundreds if not thousands more time on it.
[1]: https://github.com/Orange-OpenSource/hurl