On Tue, Jun 11, 2013 at 10:00:56AM -0700, Junio C Hamano wrote: > Michael Haggerty <mhag...@alum.mit.edu> writes: > > * When reviewing other peoples' code, be tactful and constructive. Set > > high expectations, but do what you can to help the submitter achieve > > them. Don't demand changes based only on your personal preferences. > > Don't let the perfect be the enemy of the good. > > I think this is 30% aimed at me (as I think I do about that much of > the reviews around here). I fully agree with most of them, but the > last sentence is a bit too fuzzy to be a practically useful > guideline. Somebody's bare minimum is somebody else's perfection. > An unqualified "perfect is the enemy of good" is often incorrectly > used to justify "It works for me." and "There already are other > codepaths that do it in the same wrong way.", both of which make > things _worse_ for the long term project health.
One thing that I think is missing from these proposals so far is some clear indication that a review should not be confrontational. Consider the following two review comments (taken from a recent example that happened to stick in my mind, but I don't want to single out any one individual here): Ugh, why this roundabout-passive-past tone? Use imperative tone like this: ... vs. We normally use the imperative in commit messages, perhaps like this? ... Both say the same thing but the first immediately puts the submitter on the defensive. If I see something like that on one of my patches I have to consciously resist the urge to reply immediately and instead review what I'm about to send once I've calmed down. I realise that we shouldn't take offence to review comments, but we are all human and it is sometimes hard not to take things personally. In the examples above, the first makes it feel like the submitter is fighting to get a patch included, but the second feels like we're collaborating to get to the best result for the project. As my mother would say, "politeness costs nothing" ;-) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html