Well, from my perspective it seems common practice in most open source projects which are hosted on GH that maintainers at least consider PRs and typically only reject if the PR is flawed, incomplete or somehow adds feature creep.

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.

It takes time to validate a PR, to test it, to verify it. He is not being paid for his time, he does not owe -anyone- his time.

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.

The PR contributor was not paid either to investigate the bug, reproduce it, write a patch and test it.

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.

And when maintainers respond to a significant amount of work involved in a PR for a bug with a note that they aren't interested because it's "boring" then they can be critiqued for being a jerk, because they decided to be a jerk.

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.

I thought basic etiquette was issue to discuss before PR?

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?

I agree that should be the basic etiquette.

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.

> 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

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.

Sorry if you thought I thought you were implying pressure. Not at all.

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.

> Sorry if you thought I thought you

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.

For what its worth I agree with you

I worked with a person who happens to have one of the most popular OSS Packages of my industry.

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.

There's been a request going for several years now to disable Pull Requests on GitHub[0]. They allow project maintainers to disable Issues, they should also be allowed to disable PRs rather than use automation to close any opened PR. Other SCM products (e.g. GitLab) offer the ability to make PRs available only to project members, or disable them completely.

[0] https://github.com/dear-github/dear-github/issues/84

Which is exactly what I suggested - avoid strife over mismatched expectations with a one liner. I would take your first paragraph to actually strengthen my assumption that Kinder treatment of PRs is the norm and that's why the many projects you mention add that line.

I'm not sure the practice is that common when the maintainer works for one of the largest 5 software companies in the world and that company is using the code.