zlacker

>>Philpa+(OP)
> new contributors make PRs. they make silly simple mistakes due to lack of experience; you point them out and they get fixed. this can be fun, for a time. what it’s teaching you is that you personally are responsible for catching mistakes.

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.

>>gtirlo+W4
This is true, but then the corrollary is that new PRs need to come with this higher, rigorous level of test coverage.

And then that becomes a bit of a barrier to contribution -- it's a tradeoff

I often write an entirely new test harnesses for a feature, e.g. for https://www.oilshell.org, particularly using other implementations as "oracles". All of these run in the CI - https://www.oilshell.org/release/latest/quality.html

The good thing is that it definitely helps me accept PRs faster. Current contributors are good at this kind of exhaustive testing, but many PRs aren't

Even so, I do find myself simply adding test coverage from time-to-time -- that's an important job of a maintainer