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 13, 2013, 03:45 UTC
Message-ID
<51B9406E.30104@alum.mit.edu>
In-Reply-To
<7vehc72j46.fsf@alter.siamese.dyndns.org>
On 06/12/2013 10:02 PM, Junio C Hamano wrote:
Show 45 quoted lines
> Michael Haggerty <mhagger@alum.mit.edu> writes:
> 
>> I would prefer a community standards document that looks more like this:
>> ...
>>
>> * Be welcoming to new community participants.  Help them get oriented,
>> and be patient with their questions.  Gently introduce them to our
>> community standards, above all by setting a good example yourself.
> 
> I agree that on-boarding is an important process.
> 
> In addition to the reviews I'd give to regulars, I personally try
> to do some of these things:
> 
>  - Even in a negative review, end the message with "Thanks".  More
>    important is to express that the particular patch is rejected but
>    contributor's future contribution (either a reroll or a separate
>    topic) is welcome.
> 
>    This is free, and there is no reason not to be nice.
> 
>  - Point out problems in a milder way than usual.  Instead of saying
>    "Why is this done like so?", risking to be misinterpreted that I
>    am saying the patch did something wrong and the contributor was a
>    horrible programmer, rephrase it to "Hmph, this may work in such
>    and such cases, but I wonder how well it would in this case?",
>    followed by "How about going this route instead, which would
>    cover all these cases?"
> 
>    Doing so is more time consuming at reviewers' end; once you know
>    the current design well enough, you can immediately smell a wrong
>    approach a lot faster by just looking at code and design in a
>    patch, without having to come up with a concrete example.
> 
>  - Instead of just pointing out minor nits and have the new
>    contributor reroll, point them out, and then show how the patch
>    should have looked like, often after "-- >8 --" and the "From:"
>    line that keeps attribution.
> 
>    Again this is more work at reviewers' end.
> 
> Coaching new contributors, like mentoring GSoC students, is often
> more time consuming than scratching the same itch yourself for any
> reviewer, but it is an investment, which hopefully yields dividend
> in the longer term.

Thanks for these concrete examples / suggestions for reviewers. I remember especially that during my first contacts with the Git community I was very impressed by these very things in your code reviews and in those of other reviewers.

Are you proposing that your text should find its way into the CommunityGuidelines in some form? I hesitate to make the document *so* long, especially considering that the section for contributors would then probably also be expanded by a similar amount. But I think distilling the advice into one or two sentences, also taking into account the suggestions of others in this thread, would be a definite improvement.

When I have time I want to submit some form of CommunityGuidelines as an explicit patch, and I will try to synthesize all of the suggestions that have been made.

Michael
-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
Previous: Junio C HamanoNext: Junio C Hamano
Message 57 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.