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

Re: [PATCH] Documentation/CommunityGuidelines

From
Junio C Hamano <gitster@pobox.com>
Date
Jun 12, 2013, 20:02 UTC
Message-ID
<7vehc72j46.fsf@alter.siamese.dyndns.org>
In-Reply-To
<51B6AA7F.1060505@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
Show 6 quoted lines
> 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.

Previous: Ramkumar RamachandraNext: Michael Haggerty
Message 56 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.