I should have been clearer. The maintainers shouldn't judge the PR worthiness based on the quality of the code. Of course they should code-review, encourage the contributor to improve it, point out better ways, etc. Most contributors want to learn and improve. The PR discussion can continue as long as both contributors and maintainers feel it's helpful.
The rule is there to answer the question: What do you do when a PR 1) passes tests, 2) solves a problem, and 3) the contributor isn't interested in improving it further?
In that case, it should be merged, even if the maintainer doesn't like the code. If the maintainer feels strongly enough, they can respond with their own PR to improve the code. Maintainers shouldn't become gate-keepers.
That's better and more accurate. Anyone can code-review. We should encourage a culture where lots of code review is done. But it should be done with the idea of improving skills and coaching, not pass/fail on the PR.Unit tests enforce the correctness of the code but not its quality because bad written code may still pass all tests. And who does the code review if not the maintainers?Code quality is enforced by unit tests and encouraged/improved through code review.