A. A developer
B. That is familiar with the software stack used by the application
C. Has enough time and energy to investigate the root cause of the bug or a proper design for the feature
D. Has enough time and energy to design the fix/feature, implement it properly, write tests, jump through all the hoops
E. Send the pull request
... sometimes the PR still languishes for years or the nightmare scenario, is discarded during a big rewrite that doesn't actually cover this requirement...
So even the code being out there isn't a silver bullet.
Whether it's a good idea is debatable.
Connected to this is the fact that many PRs are kind of misaligned with the project vision, that's at least the main reason I'm rejecting PRs.
I think that's the bigger part of open source. You can fork it, change it to your needs, and not give a damn what anyone else thinks about your changes.
Because maintaining an entire fork of any non trivial software is... trivial :-)
Let's just admit that these are complex problems and frankly after watching the hype for almost 20 years, open source proved to be an alternative and a good refuge for many things but on the end user side the early hype until 2008 or so was 80% wrong.
If you don't, then you can't justify putting more work onto the maintainers of upstream for changes they may not even care about.