OP argues that the presence of the 'Pull Requests' tab is encouraging people to create pull requests, and therefore the project owner is somehow responsible for reacting to pull requests.
There's also a 'Fork' button, which is kind of prominent, so by OP's logic, people should feel encouraged to fork the project.
"But when I looked at the mailing list for the project, I saw a wasteland of good patches that were completely ignored, where the submitter would ping the list a couple times and then give up. Did it seem worth spending a week to disentangle our IP from the project in order to submit a set of patches that would, in all likelihood, get ignored? Of course not.
If you have commit access to a project that has this problem, please own the process for incoming pull requests." (from the article)
Ok, so if the mailing list is dead and your pull requests aren't the only ones being ignored, why not just fork the project and 'own the process' yourself? You could even try to contact people who tried to contribute and got ignored, and let them now that you will 'own the process for incoming pull requests'?
And if you don't have time or energy for that, why demand it from other people?
> Ok, so if the mailing list is dead and your pull requests aren't the only ones being ignored, why not just fork the project and 'own the process' yourself?
That's not necessarily straightforward even for experienced OSS contributors, but in the given context (newbies who have been encouraged to get into OSS by contributing a patch), it's really a non-starter.
Because Forks aren't easily discoverable (discussed elsewhere on this thread as well), the fork would be unlikely to gain critical mass, especially without an official sanction and prominent shoutout by the original repo. If the maintenance has truly lapsed, the owner may be too lazy to even tell people about the fork. This is backed up by the fact that they obviously haven't anointed a successor, as it were.
You can not disable PRs on github. The wiki yes, issues yes, but it's not possible to disable PRs, that simply isn't an option.
At best you can add a note/contribution guideline saying you don't accept PRs, and close them as soon as they're created, but it's not possible to prevent them.
There's also a 'Fork' button, which is kind of prominent, so by OP's logic, people should feel encouraged to fork the project.
"But when I looked at the mailing list for the project, I saw a wasteland of good patches that were completely ignored, where the submitter would ping the list a couple times and then give up. Did it seem worth spending a week to disentangle our IP from the project in order to submit a set of patches that would, in all likelihood, get ignored? Of course not.
If you have commit access to a project that has this problem, please own the process for incoming pull requests." (from the article)
Ok, so if the mailing list is dead and your pull requests aren't the only ones being ignored, why not just fork the project and 'own the process' yourself? You could even try to contact people who tried to contribute and got ignored, and let them now that you will 'own the process for incoming pull requests'?
And if you don't have time or energy for that, why demand it from other people?