git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] Documentation/CommunityGuidelines

From
Michael Haggerty <mhagger@alum.mit.edu>
Date
Jun 11, 2013, 18:52 UTC
Message-ID
<51B771D5.6030809@alum.mit.edu>
In-Reply-To
<20130611182936.GM22905@serenity.lan>
On 06/11/2013 08:29 PM, John Keeping wrote:
Show 38 quoted lines
> On Tue, Jun 11, 2013 at 10:00:56AM -0700, Junio C Hamano wrote:
>> Michael Haggerty <mhagger@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.

That's a very good point (and a good illustration, too). How do you like the new second and third sentences below?

* When reviewing other peoples' code, be tactful and constructive.
Remember that submitting patches for public critique can be very
intimidating and when mistakes are found it can be embarrassing.  Do
what you can to make it a positive and pleasant experience for the
submitter.  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.

(As Junio pointed out, the last sentence is not so great and a better replacement would be welcome.)

> As my mother would say, "politeness costs nothing" ;-)
Does your mother program C?  We could use her around here :-)
Michael
-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
Previous: John KeepingNext: John Keeping
Message 43 of 63 in “Documentation/CommunityGuidelines”
  1. Documentation/CommunityGuidelinesRamkumar Ramachandra, Jun 10, 2013
  2. Célestin MatteJun 10, 2013
  3. Matthieu MoyJun 10, 2013
  4. Robin H. JohnsonJun 10, 2013
  5. Junio C HamanoJun 10, 2013
  6. Jonathan NiederJun 10, 2013
  7. Ramkumar RamachandraJun 10, 2013
  8. A Large Angry SCMJun 10, 2013
  9. Ramkumar RamachandraJun 10, 2013
  10. A Large Angry SCMJun 10, 2013
  11. Felipe ContrerasJun 11, 2013
  12. Ramkumar RamachandraJun 11, 2013
  13. Michael HaggertyJun 11, 2013
  14. Felipe ContrerasJun 11, 2013
  15. Ramkumar RamachandraJun 11, 2013
  16. Felipe ContrerasJun 11, 2013
  17. Thomas RastJun 11, 2013
  18. Ramkumar RamachandraJun 11, 2013
  19. Michael HaggertyJun 11, 2013
  20. Felipe ContrerasJun 11, 2013
  21. Ramkumar RamachandraJun 11, 2013
  22. Michael HaggertyJun 11, 2013
  23. Ramkumar RamachandraJun 11, 2013
  24. Junio C HamanoJun 11, 2013
  25. Felipe ContrerasJun 11, 2013
  26. Felipe ContrerasJun 11, 2013
  27. Brandon CaseyJun 11, 2013
  28. Theodore Ts'oJun 12, 2013
  29. Ramkumar RamachandraJun 12, 2013
  30. Felipe ContrerasJun 12, 2013
  31. Felipe ContrerasJun 11, 2013
  32. Thomas RastJun 11, 2013
  33. Felipe ContrerasJun 11, 2013
  34. Thomas RastJun 11, 2013
  35. Felipe ContrerasJun 11, 2013
  36. Junio C HamanoJun 11, 2013
  37. Michael HaggertyJun 11, 2013
  38. John KeepingJun 11, 2013
  39. Ramkumar RamachandraJun 11, 2013
  40. John KeepingJun 11, 2013
  41. Ramkumar RamachandraJun 12, 2013
  42. John KeepingJun 12, 2013
  43. Michael HaggertyJun 11, 2013
  44. John KeepingJun 11, 2013
  45. Philip OakleyJun 11, 2013
  46. John SzakmeisterJun 12, 2013
  47. Jakub NarebskiJun 12, 2013
  48. Philip OakleyJun 12, 2013
  49. Felipe ContrerasJun 11, 2013
  50. Jeff KingJun 11, 2013
  51. Junio C HamanoJun 11, 2013
  52. Felipe ContrerasJun 11, 2013
  53. Theodore Ts'oJun 12, 2013
  54. Felipe ContrerasJun 12, 2013
  55. Ramkumar RamachandraJun 12, 2013
  56. Junio C HamanoJun 12, 2013
  57. Michael HaggertyJun 13, 2013
  58. Junio C HamanoJun 13, 2013
  59. Felipe ContrerasJun 11, 2013
  60. Ramkumar RamachandraJun 11, 2013
  61. Thomas AdamJun 13, 2013
  62. Felipe ContrerasJun 13, 2013
  63. Christian CouderJun 14, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.