I used to have this problem then I figured that this takes too much time and it is also frustrating. So what I ended up doing it that I added some code quality

I used to have this problem then I figured that this takes too much time and it is also frustrating. So what I ended up doing it that I added some code quality checkers that will break the build if the PR is shit. If not then I usually approve it after glossing over it. The thing is that most of these PRs are small and very localized. The potential to do damage is very low. I'd rather have some new feature implemented with some not-so-stellar code that's hidden behind an interface then doing it myself. I think there is a goldilocks zone between perfection (and being a control freak) and a steaming pile of crap where the stuff you're working on has a clean architecture and it is acceptable to have a few poorly written modules. I usually end up rewriting them anyway when I have time and they perform poorly. By that time the contributor is usually either long gone or already improved their skills so they don't mind me tampering with the code. TL;DR: after it passes the tests / quality checker I just merge them and fix them later if they are too crappy. All in all the project benefits more from this compared to too strict coding standars.