Here’s another strategy: submit with you PR a sufficient argument as to its correctness. This could be unit tests at a bare minimum, constructive types, propert

Here’s another strategy: submit with you PR a sufficient argument as to its correctness. This could be unit tests at a bare minimum, constructive types, property tests, documentation, formal proofs, etc. Whatever sufficient is for what you’re doing. Reviewers: don’t read every line of code like you’re the lone avenger standing against all the “bad code,” in the world. Stop being a gatekeeper. Check that the author did their homework: is the argument sufficient and convincing enough? Review their tests, documentation, types, etc. It’s a lot easier to debug their proof than it is to piece together every line of code and verify it by hand. Handle formatting and linting with automation. Write style guides so that style is consistent across the code base. Build empathy for your operations, packagers, maintainers by ensuring the release process has affordances to test code in a production environment before going live to all users. Write specs and designs before hand, as your building the software, and in retrospect. The other kind of fatigue is author fatigue. Here’s 4 hours of work plus another hour pre-reviewing everything and wrapping it all up. Fingers crossed you don’t find any nitpicks that will put off my code from merging another day because you couldn’t be bothered to review anything until the last hour before EOD. It turns out what few empirical studies exist on code review effectiveness there are seem to agree that reviewers are noticeably ineffective at catching errors if they read more than 200-ish LOC per hour. Including your own code. So do consider making smaller changes. A 1200-line of change PR is difficult to review unless you’ve provided an iron-clad proof.