> 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 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
