The overhead of working out where the people who maintain the code are is usually higher than just fixing the bug I found. This is doubly true if the bug is bad enough that I need to temporarily fork the repo to deal with it.

In the same way that the maintainers don't have an obligation to review my PR, I don't have an obligation to go find them and learn how to use IRC/bugzilla/mattermost/mailing lists/smoke signals/yodelling to communicate with them with the exact secret handshake to get a review. I can just throw a PR out there, point our code at my fork, rebase it whenever they make changes, and otherwise ignore their requirements until they either fix the bug themselves or merge my code.

In usual circumstances, free work is generally appreciated. But I imagine it's a bit different with code, as most people prefer writing code to reading it.

In the case of a bug in software you didn't write, you can spend hours reading and debugging a foreign codebase, and end up writing nothing but a one-line fix and a ten-line test case.

There is such a thing as open source project with "pull requests welcome" in readme and whole elaborate "how to contribute" wiki chapter. Except when you follow that wiki to the T, it still ends up ignored because no one is reading pull requests. It is not that these contributions are going out of nowhere, from clueless people who dont realized maintainers dont want pull requests. Pretty often maintenners wanted pull requests, made sure to promote the option and then found themselves unable/unwilling to merge them in.

I am not saying projects must merge in pull requests. I am saying they should not have "please contribute it is welcome" messages in their readmes.

And on second plan, there are those campaigns to make people contribute. And shaming of companies/people for freeloading if they dont contribute - especially here on HN. Again, if then people conclude that contribution is something expected, it is not only their own fault.

This, big time. It's a matter of setting expectations. If you don't want PRs, don't make it seem like you want PRs.

Early in the project the maintainer(s) are super-excited of their new baby. Later on they burn out and move on to do different things. The PR guides are written in the first stage, while PRs get ignored in the latter.

To be explicit: I agree.

But I still think it's basic decency to close the PR and tell them No. Or if you plan to leave it around make a comment to that effect.

There are many projects where just doing that would be the equivalent of a full time position. Even saying no requires a skilled review.

If you are rejecting all PRs, that doesn't require skilled review -- a bot can do it.

A bot should do it. Because sometimes people throw a tantrum, so it's easier to just ignore a PR. Or a maintainer might post a quick reply, only to be bitten later on. I love and live by open source, but the drama can be exhausting.

Are you really open source in spirit at that point though?

Yes. Both the cathedral and the bazaar are valid approaches to OSS project management, with pros and cons.

For those curious apart from myself:

Cathedral -> centralized control Bazaar -> decentralized control

https://opensource.stackexchange.com/questions/511/whats-the...

"open source" doesn't mean "accepting drive-by contributions from unknown authors". "open source" means "open source". If you want to apply your patches, you're free to fork the repo.

Is there no way to just have a script add a comment on every new PR saying "Due to insufficient staff, your PR may not be reviewed for a considerable amount of time."?

Your code is important to us. Please stay on the line, and the next available reviewer will answer your code. Due to unusually high code volumes, this response may take longer than usual.

Something like that?

All that's missing is an autoplay embed with some hold muzak ;-)

I think the issue is about letting people know that PRs won't be reviewed/merged before they bother putting a lot of effort into them (both the commit itself and setting up/documenting the PR).

It would be nice if you could turn off accepting pull requests whilst keeping the project alive.

This has always been a weird quirk of GitHub. You can disable issues, boards, wikis, but pull requests cannot be toggled. It's a pain point for lots of projects: those closed to contributions, those which are not primarily code (issues-only), those that use a different platform for review (e.g. Gerrit), ...

Why does GitHub persist? It's not like forcing the feature enabled helps anyone. The maintainers will still not merge if they don't want to. There are bots in the marketplace that will close PRs with a message. GitLab has a toggle. Why is this so important to GitHub?

They are currently not reviewing or merging PRs, closing them to only later reopen or whatever is probably even more overhead.

I think if it is made clear "don't hold your breath" and someone decides to contribute anyway, well, it's only fair to wait.