When working on a large project, knowing whether or not a pull request is "good" can be difficult. We can find ourselves in abstract discussions of what the best approach should be or leaving review that "maybe you could fix X too". While these conversations have value, they are not pragmatic and don't directly lead to code changes and PRs being merged.

I am working on having a mindset focused on incremental improvement. If a PR makes an undeniable improvement to the code base and does not introduce any bugs or debt, then it should be merged. If every PR can provide some improvement and be turned around quickly, a team can rapidly rid themselves of the problems they spend so much time discussing.

It is hard to walk the line between "fix everything" and "make the project better", but I think it can (and should) be done. Identify the core issues, create PRs to fix them, and merge the PRs. The ideal PR is likely small and targeted instead of large and perfect. Over time, the smaller PRs can be merged faster, provide a smaller surface area for bugs, and approach the perfect solution.