Yeah of course, if someone has sent a patch I would consider it a duty of the maintainer to review it, maybe rework a little if needed and commit with the necessary attribution. But I don't think it's the end of the world if a patch isn't accepted by the upstream. Assuming the pace of development isn't too fast it is not too much effort to maintain a friendly fork and occasionally rebase it.
There is a fundamental difference between the duties of a maintainer and a developer. Just because some people are both doesn't mean they are the same thing.
And that's what makes it not neccessarily less work at all to say "patches welcome", if you take that approach.
Reviewing patches is real work, and often turns into mentoring/helping/directing the code, if you want to keep the software from turning into a ball of mess.
(Or saying "no, patches not welcome for this one we won't be doing it", or "not unless you can find an elegant way to implement it, according to me")
I don't find that reviewing patches (with all it entails as above) is often even less work than doing it yourself.
> I don't find that reviewing patches (with all it entails as above) is often even less work than doing it yourself.
And that's why it's offensive when you request some feature but they just brush you off by saying "patches welcome". Let's say you show up with a patch. Now they'll engage with you, right? Nope. They can just as easily brush you off.
Maintainers know their projects and could have gotten it done in a fraction of the time it takes external contributors to do it. Truth is they probably don't really care about your feature or your contribution. Instead of just saying that they don't want it, they put up these barriers in order to subtly tell people to go away.
Wouldn't be so bad if it wasn't for the generally dismissive attitude. You ask for something, they imply it's beneath them and pretty much challenge you to show them the code. Does it mean they are prepared to accept your code should you rise up to their challenge? No.
* If people really don't want the feature and don't have time to review/work with you on a patch, they SHOULD just say so, instead of saying "patches welcome". Part of this is cultural, it's hard to say no.
* The other end of this bargain is we have to accept a "no", have to realize that the reason the package is good is because the maintainers keep it from becomming spagetti by saying no sometimes too, and by making priorities.
* EVEN THOUGH it can take maintainers time to work with a patch, there is STILL reason to ask for a patch. Sometimes it WILL take LESS time. But ALL the time it's part of how you develop new collaborators -- the person you work with on a patch may later be a co-maintainer or later take over as maintainer. You are increasing the bus factor by mentoring additional developers in the project.
There is a fundamental difference between the duties of a maintainer and a developer. Just because some people are both doesn't mean they are the same thing.