The problem isn't reverting commits that are bad,
it's reverting
commits solely because they haven't been reviewed. In a pre-commit
review system, the equivalent to the proposed 72-hour rule would be
letting unreviewed code languish without comment. Both of these are
bad things.
The point is, people's code should only be rejected with some specific
reason that either a) lets them fix it and resubmit, or b) tells them
definitively that it's not wanted and they shouldn't waste further
effort or hope on the project. Whether you're using
review-then-commit or commit-then-review, one of the most demoralizing
things you can do to a volunteer's contributions is say "nobody cares
enough to provide any feedback on your code, so we're just going to
reject it by default".
+1
As a volunteer person, I'm fine if code I commit is reverted based on
it sucking, being too complicated, being too ugly, etc provided there
is actually some objection to the code. However, I'd be rather
offended if it was reverted on the basis of no one got around to
looking at in the last 3 days, since that is something essentially out
of my control.
As it stands, trivial one line changes aren't even reviewed in 72 hours.
-bawolff