Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Getting merged

8,758 views

Published on

Getting Merged. All about social coding.

Published in: Technology

Getting merged

  1. 1. Getting Merged All about social coding Yo-An Lin @c9s
  2. 2. Pull Request, What's that? 什麼碗糕
  3. 3. The  old  school  open  source   collaboration 以往的開源協作
  4. 4. ...  are  done  by  patches  and  mailing  lists. 是靠 patch + mailing list 完 成的
  5. 5. sometimes  you  can  only  contact  the   maintainer  with  an  e-­‐mail... 有時候你甚⾄至只有 e-mail
  6. 6. ⼀一鍵寄出,⾳音訊全無
  7. 7. You  have  to  poke 戳戳樂,如果你很愛玩的話
  8. 8. 無⽌止境合併衝突
  9. 9. The  new  age  of  open  source   collaboration 新時代的開源協作
  10. 10. ..  are  done  by  pull  requests 是靠 Pull Request 來完成的
  11. 11. Introduced by GitHub in 2008/2009
  12. 12. It  combines  review,  merge,  and  social 集檢閱, 合併, 社交於⼀一⾝身
  13. 13. One Click Merge
  14. 14. It  reduces  the  cost  of  communication  &   efforts 減少以往的溝通成本
  15. 15. How does it work? Pull Request 如何運作?
  16. 16. For what reason? 發什麼 PR
  17. 17. "I  am  doing  +ine!  why  do  I  have  to  send   the  PRs?!" 我好好的,發什麼 PR ?
  18. 18. http://wowquote.tw/quote/371
  19. 19. If  you  want  to  enrich  your  CV 您的 CV 很無聊嗎?
  20. 20. Then  you  should  send  PRs 那就送 PR 吧!
  21. 21. Do  you  want  to  claim  that  you're  the   contributor  of  XXX  project? 你想要聲稱是某專案的貢獻 者
  22. 22. Then  you  should  send  PRs 那就送 PR 吧!
  23. 23. Seriously, 認真的說,
  24. 24. Once  you  merged  the  changes  to   upstream ⼀一旦可以合併本地修改到上 游
  25. 25. 1.  Reduces  the  cost  of  maintenance 1. 減少維護成本
  26. 26. 2.  Helps  you  update  bug  Nixes  from   upstream  without  pain 2. 無痛接收新的 BugFix
  27. 27. 3.  Helps  you  avoid  merge  conNlicts  for   the  future 3. 避免未來的修改衝突
  28. 28. 4.  The  document  will  be  maintained 4. 還有⼈人持續幫你維護⽂文件
  29. 29. 有這麼好康還說什麼
  30. 30. Rejected 駁回
  31. 31. Your  PR  might  be  rejected  if  ... 你的 PR 有可能會遭到駁回, 如果...
  32. 32. It  doesn't  match  the  direction  of   the  project 與專案進⾏行⽅方向有衝突
  33. 33. It's  out  of  scope 或者超出範圍
  34. 34. It  will  break  the  compatibility
  35. 35. A Real World Case:
  36. 36. 遭到駁回
  37. 37. The scientific ways to send pull requests
  38. 38. RFC First 提案與回饋
  39. 39. Ask  First,  Shoot  later 問清楚,再動⼿手
  40. 40. 先射後補也會讓⼈人尷尬
  41. 41. Nobody is somebody 沒有⼈人就是你
  42. 42. "This  project  is  too  large!  What   can  I  do?"
  43. 43. Anything  can  be  included  in  a  pull   request
  44. 44. Build  system,  Documentation,   Coding  style,  Designs,  Icons...  etc
  45. 45. Don't  limit  yourself
  46. 46. Start small 從⼩小處著⼿手
  47. 47. Small  things  usually  would  get   merged  easily
  48. 48. Spaces,  Wordings,  Typos,  Small   Nixes...  etc
  49. 49. https://twitter.com/jserv/status/552725130690826240
  50. 50. "That letter [the last s] is sad because all the others have those things [=] below them and it does not." This patch fixes the tragedy so all the letters can be happy again.
  51. 51. Read The Contribution Document
  52. 52. Big  projects  have  their  own  coding   rules  and  contribution  rules,  you   have  to  read  them  carefully.
  53. 53. If  you're  not  doing  it  right  on  the   coding  style,  you're  wasting  your   time  to  get  merged.
  54. 54. For  example,  the  golang  team  asks   you  to  run  `go  fmt`  when   everytime  you  submit  a  patch
  55. 55. http://django-oauth-toolkit.readthedocs.org/en/latest/contributing.html
  56. 56. Divide and Conquer 分⽽而治之
  57. 57. When  you  want  to  do  something   big
  58. 58. You  should  divide  it  into  small   separated  pull  requests
  59. 59. Good  impression  helps  a  lot
  60. 60. 這是⼀一個 "最熟悉的陌⽣生⼈人" 的概念
  61. 61. Detail matters 細節
  62. 62. Busy  people  are  usually  too  busy   to  listen,  think  or  understand  ...
  63. 63. A  good  brief  helps  reviewer   quickly  understand  the  changes
  64. 64. BugFix  PR  should  contain  a  failing   test  case  and  the  way  to   reproduce  the  problem.
  65. 65. To  proof  it's  author's  fault
  66. 66. Or..  to  prevent  things  like  this...
  67. 67. At  least  it  prevents  from  the  time-­‐ consuming  communication
  68. 68. PR For Feature • Objective • Summary • Effect (Or side effect) • Tests
  69. 69. Safety 安全
  70. 70. Maintainers  usually  worry  about   breaking  backward  compatibility,   build  system,  dependencies...  etc
  71. 71. It's  also  important  to  get   continuous  testing  pass
  72. 72. When  adding  new  features,  good   tests  also  help  author  to  verify  the   changes
  73. 73. Write  down  the  side  effects  to   show  your  careful  thoughts  to  the   author
  74. 74. Just Ask 問就對了
  75. 75. Asia  people  usually  are  too  shy  to   ask  
  76. 76. Sometimes  people  just  don't  write   down  their  concern  on  GitHub 有時專案作者很少會寫下⾃自 ⼰己的⼼心中顧慮的部分
  77. 77. When  you  don't  get  reply,  you   should  ask
  78. 78. "If  you  have  any  concern,  please   let  me  know"  also  ping  them  back   to  reply
  79. 79. Timezone matters 時區有差
  80. 80. Human  beings  usually  check  their   e-­‐mail  in  the  morning
  81. 81. For  company  sponsored  projects,   people  usually  check  newly   opened  issues  in  daylight.
  82. 82. For  just-­‐for-­‐fun  projects,  people   usually  check  the  issues  in  night.
  83. 83. Some  non-­‐Asia  people  usually   don't  check  e-­‐mail  or  work  on   weekend
  84. 84. Don't  expect  their  e-­‐mail  on  the   weekend
  85. 85. They  have  life!
  86. 86. And  for  Asia   people,  you  can   just  poke  around,   they  will  reply   you  all  day
  87. 87. San Francisco people get up at 01:00 AM Taipei Time (GMT+8)
  88. 88. And  they  get  off  work  at  10:00   AM  Taipei  Time  (GMT+8)
  89. 89. People from London get up at 15:00 PM Taipei Time
  90. 90. They  are  having  their  lunch  while   you're  having  dinner!
  91. 91. To  get  response  instantly 要得到快速回覆
  92. 92. You  should  send/reply  at  the  correct   time 你應該在正確的時間點發信
  93. 93. And  you  shall  mostly  get  the   response  quicker  then  you   thought.
  94. 94. And  once  you  get  the  ping,  you   have  to  pong  back  quickly
  95. 95. First  in,  First  out
  96. 96. Last  In,  Never  Out
  97. 97. Because  they've  got  off  work
  98. 98. The lines on this map show 12 cities’ typical working day, beginning with 9 AM on the right and ending at 5 PM on the left, and each workday’s overlap with time zones around the world. Each clock shows that city’s workday overlap with other cities’ and the best time to schedule a call. https://hbr.org/2010/10/vision-statement-why-mumbai- at-1-pm-is-the-center-of-the-business-world Timezone overlapping
  99. 99. World Clock app for multi-timezone
  100. 100. Countersign 連署
  101. 101. Votes  can  show  the  need  to  the   author
  102. 102. Partnership 合作夥伴
  103. 103. By  being  reviewed  or  reviewing   PRs  from  others  
  104. 104. you  will  know  good  people
  105. 105. Different  from  LinkedIn,
  106. 106. You  know  their  code  &   personality
  107. 107. Negotiation 交涉
  108. 108. Screenshot Rocks 有圖有真相
  109. 109. Screencast  even  better!
  110. 110. https://github.com/c9s/CLIFramework#automatic-zsh-completion-generator
  111. 111. LICEcap https://github.com/lepht/licecap
  112. 112. Questions? 問題?

×