[readams]

The worst maintainers are the ones who refuse to say no when they mean no or want to say no. I've seen maintainers waste weeks or months of a contributors time on work that they never intend to accept because they're trying to avoid confrontation up front.

[kibwen]

I'd say that's a distinct skill that requires a different approach. Big projects have this problem less, because they have so many conflicting stakeholders and they get so much more practice rejecting random patches. But for little projects with one or few maintainers it's easy to look at every random contribution and be flattered that someone would bother to take the time to try and give back, which at the same time predisposes you to feeling like rejecting them would be some sort of betrayal. It's important to be magnanimous here when possible, but at the same time when they inevitably ask "why wasn't this accepted?" sometimes there simply isn't a more satisfying answer than "this doesn't fit with our unspoken philosophy of what the project should be".

To use an example of a project I've contributed to, Dungeon Crawl Stone Soup has an explicit wiki page for "patches that we will not accept, so don't even bother asking": https://crawl.develz.org/wiki/doku.php?id=dcss:planning:wont...

[Karrot_Kream]

Working with the DCSS maintainers is great though. I recently contributed some code to put FreeBSD support into DCSS, and it was great working with them!

[stestagg]

I like this approach, maybe they should try it for science and maths too.

Just post a list of all the major unsolved scientific questions, and then everyone will know not to bother with them, because they're unsolvable...