[notepad0x90]

It's not even about the maintainer, I can't maintain a large and complex project supported by lots of maintainers on my own, as a fork. But I can make fixes available for other users as a PR..until it's merged (or not). This is about users of the software, how will taking away PRs affect them?

I'm not wondering why that PR is not accepted, maintainers have every right to ignore or reject PRs. But this discussion is about taking away the ability to even create PRs that other users of the software an discover. This is a user-hostile behavior fueled solely by laziness and pettiness.

[FeistySkink]

> This is a user-hostile behavior fueled solely by laziness and pettiness.

Damn, that last quip is really poisoning the well here. As a maintainer, not being paid for my projects or contributions, I have every right to decide how and if I want to accept contributions.

[notepad0x90]

who said otherwise? don't accept contributions, don't review them. I already conceded your rights there. This is about preventing other people from posting PRs in the first place, not about if you accept or reject them. Two different topics.

[duskdozer]

>I can't maintain a large and complex project supported by lots of maintainers on my own, as a fork

Do you need to "maintain" a complex project? Why can't you just add the patches you want on your fork and update as far as it suits you? Just as the upstream doesn't have to review or accept PRs, neither do you. Users can still see the network of forks, and ime there are few that are actively updated.

[notepad0x90]

How can i tell why every fork was created? How can I tell it'll fix my issue?

The idea of maintaining a fork for the sake of a patch affecting only one version of the original software is silly. Not only that, others mentioned "networks" but how do users tell what I patched, diff every fork one by one? Perhaps there is a feature I don't know about since PRs just work for me.