Every team I've worked with that was feeling exhausted about code contributions actually needed to focus on better documenting guidelines but most importantly, improve CI. Catching silly mistakes is the textbook definition where automating stuff can help the most. This should improve reviewer's peace of mind and speed things up because people will work by themselves to fix things before asking for a review.
I don't know what's the CI situation in the Rust project but if it's anything like what I'm used to, it probably needs improvement. Adding more human-hours to reviewing things isn't sustainable.
CI is good. more tests are good. but there's a limit to how much they can catch.
here is an example: there is an internal type checking API called [`resolve_vars_if_possible`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_infer/...). this needs to be called on the output of almost any call to `.normalize()`, or you will get an internal compiler error. the conditions under which you get an ICE are quite complicated; sometimes you need 6 or more items in the crate with `impl Trait` or type_alias_impl_trait or const generics involved. but it's very easy to see there's a bug just by looking at the code and seeing the missing `resolve_vars()` call.
how can we automate this? well, rustc has a mechanism for "internal lints", but they're somewhat annoying to write - you're basically writing a new compiler pass, and it needs to not have false positives. it's much easier to just catch this one instance. so the reviewer, who's already burned out, does this quick manual review instead.
anyway, thanks for writing this post, and for featuring that awesome message/art/logo/thing at the end \m/