Getting MergedAll about social coding

Yo-An Lin@c9s

Pull Request, What's that? 什麼碗糕

The  old  school  open  source  collaboration

以往的開源協作

...  are  done  by  patches  and  mailing  lists.

是靠 patch + mailing list 完成的

sometimes  you  can  only  contact  the  maintainer  with  an  e-­‐mail...

有時候你甚⾄至只有 e-mail

⼀一鍵寄出，⾳音訊全無

You  have  to  poke

戳戳樂，如果你很愛玩的話

無⽌止境合併衝突

The  new  age  of  open  source  collaboration

新時代的開源協作

..  are  done  by  pull  requests

是靠 Pull Request 來完成的

Introduced by GitHub in 2008/2009

It  combines  review,  merge,  and  social

集檢閱, 合併, 社交於⼀一⾝身

One Click Merge

It  reduces  the  cost  of  communication  &  efforts

減少以往的溝通成本

How does it work?

Pull Request 如何運作?

For what reason? 發什麼 PR

"I  am  doing  +ine!  why  do  I  have  to  send  the  PRs?!"

我好好的，發什麼 PR ?

http://wowquote.tw/quote/371

If  you  want  to  enrich  your  CV

您的 CV 很無聊嗎?

Then  you  should  send  PRs

那就送 PR 吧!

Do  you  want  to  claim  that  you're  the  contributor  of  XXX  project?

你想要聲稱是某專案的貢獻者

Then  you  should  send  PRs

那就送 PR 吧!

Seriously,

認真的說,

Once  you  merged  the  changes  to  upstream

⼀一旦可以合併本地修改到上游

1.  Reduces  the  cost  of  maintenance

1. 減少維護成本

2.  Helps  you  update  bug  Nixes  from  upstream  without  pain

2. 無痛接收新的 BugFix

3.  Helps  you  avoid  merge  conNlicts  for  the  future

3. 避免未來的修改衝突

4.  The  document  will  be  maintained

4. 還有⼈人持續幫你維護⽂文件

有這麼好康還說什麼

Rejected 駁回

Your  PR  might  be  rejected  if  ...

你的 PR 有可能會遭到駁回，如果...

It  doesn't  match  the  direction  of  the  project

與專案進⾏行⽅方向有衝突

It's  out  of  scope

或者超出範圍

It  will  break  the  compatibility

A Real World Case:

遭到駁回

The scientific ways to send pull requests

RFC First 提案與回饋

Ask  First,  Shoot  later

問清楚，再動⼿手

先射後補也會讓⼈人尷尬

Nobody is somebody 沒有⼈人就是你

"This  project  is  too  large!  What  can  I  do?"

Anything  can  be  included  in  a  pull  request

Build  system,  Documentation,  Coding  style,  Designs,  Icons...  etc

Don't  limit  yourself

Start small 從⼩小處著⼿手

Small  things  usually  would  get  merged  easily

Spaces,  Wordings,  Typos,  Small  Nixes...  etc

https://twitter.com/jserv/status/552725130690826240

"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.

Read The Contribution

Document

Big  projects  have  their  own  coding  rules  and  contribution  rules,  you  have  to  read  them  carefully.

If  you're  not  doing  it  right  on  the  coding  style,  you're  wasting  your  

time  to  get  merged.

For  example,  the  golang  team  asks  you  to  run  `go  fmt`  when  

everytime  you  submit  a  patch

http://django-oauth-toolkit.readthedocs.org/en/latest/contributing.html

Divide and Conquer 分⽽而治之

When  you  want  to  do  something  big

You  should  divide  it  into  small  separated  pull  requests

Good  impression  helps  a  lot

這是⼀一個 "最熟悉的陌⽣生⼈人"

的概念

Detail matters 細節

Busy  people  are  usually  too  busy  to  listen,  think  or  understand  ...

A  good  brief  helps  reviewer  quickly  understand  the  changes

BugFix  PR  should  contain  a  failing  test  case  and  the  way  to  reproduce  the  problem.

To  proof  it's  author's  fault

Or..  to  prevent  things  like  this...

At  least  it  prevents  from  the  time-­‐consuming  communication

PR For Feature

• Objective

• Summary

• Effect (Or side effect)

• Tests

Safety 安全

Maintainers  usually  worry  about  breaking  backward  compatibility,  build  system,  dependencies...  etc

It's  also  important  to  get  continuous  testing  pass

When  adding  new  features,  good  tests  also  help  author  to  verify  the  

changes

Write  down  the  side  effects  to  show  your  careful  thoughts  to  the  

author

Just Ask 問就對了

Asia  people  usually  are  too  shy  to  ask  

Sometimes  people  just  don't  write  down  their  concern  on  GitHub

有時專案作者很少會寫下⾃自⼰己的⼼心中顧慮的部分

When  you  don't  get  reply,  you  should  ask

"If  you  have  any  concern,  please  let  me  know"  also  ping  them  back  

to  reply

Timezone matters 時區有差

Human  beings  usually  check  their  e-­‐mail  in  the  morning

For  company  sponsored  projects,  people  usually  check  newly  opened  issues  in  daylight.

For  just-­‐for-­‐fun  projects,  people  usually  check  the  issues  in  night.

Some  non-­‐Asia  people  usually  don't  check  e-­‐mail  or  work  on  

weekend

Don't  expect  their  e-­‐mail  on  the  weekend

They  have  life!

And  for  Asia  people,  you  can  just  poke  around,  

they  will  reply  you  all  day

San Francisco people get up at 01:00 AM Taipei Time (GMT+8)

And  they  get  off  work  at  10:00  AM  Taipei  Time  (GMT+8)

People from London get up at 15:00 PM Taipei Time

They  are  having  their  lunch  while  you're  having  dinner!

To  get  response  instantly

要得到快速回覆

You  should  send/reply  at  the  correct  time

你應該在正確的時間點發信

And  you  shall  mostly  get  the  response  quicker  then  you  

thought.

And  once  you  get  the  ping,  you  have  to  pong  back  quickly

First  in,  First  out

Last  In,  Never  Out

Because  they've  got  off  work

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

World Clock app for multi-timezone

Countersign 連署

Votes  can  show  the  need  to  the  author

Partnership 合作夥伴

By  being  reviewed  or  reviewing  PRs  from  others  

you  will  know  good  people

Different  from  LinkedIn,

You  know  their  code  &  personality

Negotiation 交涉

Screenshot Rocks 有圖有真相

Screencast  even  better!

https://github.com/c9s/CLIFramework#automatic-zsh-completion-generator

LICEcaphttps://github.com/lepht/licecap

Questions? 問題?