Yes. The "reduce the stigma" part. Having users open a PR to just get it automatically closed by a bot (which also needs to be set up) it's far less welcoming than NOT having at all a "Pull requests" tab where you can open said PR.

That said, I agree with the idea of simply removing the possibility to make external PR's. The possibility to view (internal) PR's must be there though, so that external viewers can see PRs from the mainainer(s).

I don’t think optimizing for that edge case makes a ton of sense. Having the ability to hide PRs might be a nice feature, but some people use that for stuff other than straight pull requests.

A few of those who didn't read the README, and get their PRs auto closed, might get upset at the maintainers, and write something a bit angry, making it less pleasant to be a maintainer.

You can easily do that, but what you can't do is prevent people from being angry. You can do everything in your power to prevent people from accidentally wasting their time, and you should. This is where "hide the feature" would come in.

> Really fuck em if they’re gonna stay butt hurt about it.. this should have been cleared up in kindergarten.

Such an attitude from a maintainer can piss people of and make them write angry things to the maintainer, causing him/her to quit.

Also, I remember a case where after some time someone decided that since the maintainer was not answering, it was fine to add insults and threats.

Oh please, only somebody with a ridiculously thin skin would be offended by seeing rejected his PR to a project that clearly states that does not welcome outside contributions.

I'm quite angry because I spent time investigating this problem and now it won't be fixed and it is not logical and I've lost my time.

Obviously one needs to be judicious with this, but I've scored some big wins from this. In addition to bypassing projects who don't want to accept the (IMHO) perfectly reasonable contributions, I've also some cases where the upstream project shouldn't accept my changes and I shouldn't submit them. I've got one case where I forked a package and essentially twisted it so hard that it destroys it for its original purpose, even though it now does exactly what I need. A couple of others where the upstream is obviously dead. Another case I can think of where in principle the upstream could accept it, but it adds a subtle and easy-to-misuse feature to the package that I understand fairly well having written it, but would really encourage users to mess themselves up and is hard to document properly, so I probably won't ever submit it.

It's not something I do all the time by any means... the above paragraph describes nearly all the cases where I've done it. It's 3 or 4 in as many years. But each of them was a fairly large win.

You'll then have to maintain the fork, re-applying your changes whenever the upstream repo is updated

I don't understand the anger, are you angry because he doesn't have the same opinion as you and doesn't want to make the implementation behave according to your opinion?

I guess the lesson is that there is always someone angry over something unreasonable.

People like that are very common and often very vocal.

In order to keep the IP for a project pristine (for the sake of downstream users), I would prefer never to see somebody else's copyrighted solution to a problem. If I see their contribution but I don't want to accept it, I'm forced to come up with a new creative solution that a court would (maybe, hopefully) consider original.

This is especially important for CC0/public-domain projects, where many contributors will not fully understand the implications of contributing and may not be in a position to release code into the public domain.

You are doomed, then. They can always sent a (unrequested) email to you, Cc'd to a public mailing list. The PR interface is just another equivalent way for people to send messages to you, like email.

The Github Pull Request interface is an attractive nuisance, like an unfenced swimming pool. You can't keep people out with warning signs, they won't read them. Put up a fence, though, and even the obtuse will get discouraged.

I don't want to have to set up an auto-close bot when I should be able to just untick a checkbox in the project's settings.

I don't want to have to click through PR notifications and manually close them when I should be able to just untick a checkbox in the project's settings.

That is an interesting observation. Can you elaborate on what you mean? Thanks!