Of course any maintainer is free to handle it differently, but if going against usual expectations, it would be benefitial for all involved to note reluctance to PRs prominently to the Readme.
If you don't like the way a project is being run, fork it and own it yourself.
I know that's harsh, and not idealistic, but it's the way people should really think about this. People take FOSS for granted, CONSTANTLY. And maintainers even more so.
However instead of raising a "don't work, please fix" bug s/he took the time to do all that.
Anyone that went to such length deserve basic courtesy, whether the code is accepted or refused.
Refusing a patch because it is "boring" is not respecting the time people dedicated to your project.
I would understand refusing because the patch makes an unwanted compromise on performance and the maintainer considers performance regressions as bug.
I have replied to logged issues with the question: "I don't work on this, unless you have set aside a budget that pays my hourly rate".
If the maintainer had said, "Hey, I don't have the time to review/test/verify this PR so I'm closing it for now," the backlash probably wouldn't have been quite so severe.
Starting with a PR seems to me like saying "you have nothing to tell me about how your code works, I know exactly how your code should be changed and if my changes conflict with what you're working on you should throw your code out because mine is better".
Is that wrong?
Perhaps it needs to be said more clearly on project pages and codes of conduct and participation.
(Of course, it is not reasonable to demand that an already-overworked maintainer-for-free find extra hours to have the pre-PR discussion either. It needs to be exploratory and respect the maintainers' timescales. Luckily, if you don't get the response you wanted, you can fork and hire someone else or do it yourself, and keep your fixes in the queue for others to review eventually, if they want, at whatever timescale suits them.)
Unfortunately, there seem to be quite a lot of people who would, rather than discussing ideas respectfully, instead prefer to bully and shame the maintainer.
Such as, for example, calling out perceived issues in the code publically (sometimes incorrectly), and making out how unskilled the maintainer must be, in order to put pressure on the maintainer to sacrifice their personal life and do what the bully wants.
I absolutely didn't mean to imply that. I also think that a pre-PR discussion can be useful because if the maintainer doesn't have time to say they want a PR that's a decent hint they won't have time to handle the PR.
I thought your comment was helpful and supportive.
I just wanted to clarify, for readers, that expecting anything at any stage from a maintainer can be expecting too much sometimes. It is time and work for them after all, and usually it's in their limited personal time, for free.
Sometimes, they have already exhausted all the time they could put into the project; even a brief "thanks" email is too much when you have too many for whatever available time and energy you have. People don't always realise that, when they say "the maintainer should just [...]". A lot of people wanting [...] adds up.
No problem at all.
> I thought your comment was helpful and supportive.
Thank you. I'm glad you saw it that way.
> A lot of people wanting [...] adds up.
It sounds as though you've had some tough experiences with this. I'm sorry to hear that.
He has a kid and works 8hs a day like all of us... some merge requests are two years old, he doesn't have time for all the feedback / suggestions he receives and just keeps coding in his very limited time because is what he is passionate about... people keep using it.
When the code is being used internally at Microsoft, it makes even more sense they wouldn’t take PRs.