I spent quite some time writing a patch for FreeBSD and Linux a few months ago, including getting to grips with their contribution process.
Both patches have been ignored thus far. That's okay, I understand limited resources etc. etc. Will they ever be merged? I don't know. Maybe not.
I'm okay with all of this, it's not a complaint. It's how open source works sometimes. But it also means all that time I spent figuring out the contribution process has been a waste. Time I could have spent on more/other patches.
So yeah, there's that.
It's certainly true that making the bar higher will reduce low-quality contributions, because it will reduce ALL contributions.
(aside: FreeBSD does accept patches over GitHub, but it also somewhat discourages that and the last time I did that it also took a long time for it to get reviewed, although not as long as now)
In all likelihood, if the patch had been a pull request, the pull request would have been ignored as well. Much like the thousands of pull requests that are often ignored by various larger open source projects. Ain't nobody got time to triage drive-by pull requests from unknown contributors, especially on large projects.
There's no easy solution. Much like the recent curl security kerfuffle, the signal:noise ratio is important and hard to maintain.
I think the OP's point here was that if it's a PR and it's ignored: you spent a bunch of time writing a PR (which may or may not have been valuable to you, e.g. if you maintain a fork now). On the other hand, if it was an esoteric contribution process, you spent a lot of time figuring out how to get the patch in there, but that obviously has 0 value outside contributing within that particular open source project.
GitHub PRs don't solve anything about that, but I wouldn't have to spend (waste) time figuring out the contribution process. At least I learned a few things writing the patches. I learned nothing of value dealing with git email or Phabricator. It's just work of the boring and tedious kind.
Dealing with github is the boring and tedious thing, you have to run huge amount of proprietary javascript, keep up with their weird UX changes, start X11 to open a browser to render their html, overclock your CPU for a large PR review conversation to scroll without locking up your computer for minutes, constantly click "load more" since their webpage keeps hiding comments (while still lagging massively)...
Email is simple. It's just text, there's no weird javascript or html or lag. I don't have to open X11. I can just open mutt and read or write. I can type "git send-email". It's all open source, so I can read the code to understand it, and write scripting around it. It runs on any computer with ease. Even on a slow connection, it's quite speedy.
I totally agree with you about Phabricator though.
I have some unconventional workflows. And I try not to bother anyone else with it, especially in a volunteer driven open source context. It would be selfish to do otherwise.
To be honest based on what you've written here, keeping you out of my projects sounds like a good thing. What a bunch of piss and vinegar over how other people are choosing to work in a way that works for them.
Many projects have rules about what kinds of pull requests they accept. You would still have had to familiarise yourself with those rules, as well as the usual things like coding style, testing policies, etc.
Surely the claim being made is that the overall effort was increased in this case. That makes sense to me. I guess you can debate "but by how much?" but it seems fairly clear that there is more friction than there would have been via Github PRs
Both patches have been ignored thus far. That's okay, I understand limited resources etc. etc. Will they ever be merged? I don't know. Maybe not.
I'm okay with all of this, it's not a complaint. It's how open source works sometimes. But it also means all that time I spent figuring out the contribution process has been a waste. Time I could have spent on more/other patches.
So yeah, there's that.
It's certainly true that making the bar higher will reduce low-quality contributions, because it will reduce ALL contributions.
(aside: FreeBSD does accept patches over GitHub, but it also somewhat discourages that and the last time I did that it also took a long time for it to get reviewed, although not as long as now)