Thats something a have regarding PR and code reviews: much frustration can be avoided by discussing what to do and how to do it before showing the work done (avoiding also infinite bikeshedding). Often code review talk about the strategy to do X and not the way to do X
And some people take the 'No' badly. It's frustrating having to explain that the code in a PR needs to be maintained forever, and it's the repo maintainer that will have to do it, not the contributor. A simple proposal upfront makes all the difference, and saves human effort and feelings.
This is hard. It makes you feel bad inside to tell people "No", especially when they open PR and clearly did a lot of work adding some feature.