> But it is also unclear how to improve the situation.

Then please allow me to make a few suggestions based on my limited experience.

I'll begin by saying it's not really my intention to just show up out of nowhere and demand things. When everything is done, I'll go away and the maintainers will remain. They'll continue being responsible for the project while I get to not think about it anymore. It would be disrespectful to demand that they maintain code I wrote.

The key point I want to make is: it's profoundly demotivating when maintainers don't even engage with the contributors. People spend time and effort learning a project, making the change and sending in the patches in good faith. We ask only for their genuine consideration.

If the patch has issues, it's more than enough to reply with a short review detailing what needs to change in order for the patch to be considered. The most likely result of such a review is a v2 patch set being sent with those exact changes implemented. That is the nature of peer review.

What usually happens in my experience is the patches get straight up ignored and forgotten about for an untold amount of time. Then the maintainer suddenly shows up and implements the thing himself! That's nice, in the end I got the feature wanted I guess. I just didn't get to become a contributor. I leave wondering why I even bothered to do all that work.

That treatment makes me feel like I'm beneath them, beneath their consideration. I spent days discussing a patch on a mailing list. One person had numerous objections to the idea I was proposing, I tried to address them all but then it turned out he hadn't even read the patch I sent. That seriously almost made me quit on the spot.

The word peer in peer review is extremely important. Reading the work, considering it and offering genuine thoughts, this is how people treat their peers. That is true respect, even when nothing but criticism is offered. Someone who refuses to even read our code doesn't really see us as equals. We're not fellow programmers with ideas worth considering, we're schizophrenics posting crazy talk and submitting nonsense code.

Someone contributed a bug fix to one of my projects about 6 months ago. As soon as I saw the pull request, I acknowledged it and reviewed it. I requested some simple changes, he made those changes and then I accepted it. I made it a point to engage with him so that he could get the commits into the repository and be fully credited for the contribution in the git history. His eyeballs rendered one bug shallow, I felt like that was the least I could do. I think this is a good way to improve the situation. It's certainly the way that I would like to be treated.

It's also important to be honest with oneself and the scope of the project. Sometimes people want perfectly reasonable things but the maintainer has no plans to implement them because of limited time or because they feel it's out of scope for the project. I think it's important to be polite but firm in those cases. If there's no chance that a feature will be accepted, maintainers need to make the decision as early as possible and communicate it clearly. That way people won't waste time and effort implementing a feature that will never be accepted.

> And finally, people need to be braver. You are not getting heard when you give up too easily. And if do not get your patch in, maybe create your own project, or maintain your fork, etc.

Absolutely agree. Especially the part where people create their own projects. My website is powered by a fork of an unmaintained templating engine. I actually want to rewrite all of it some day. Hopefully in my own programming language which I'm also working on as often as time allows.