The document discusses best practices for submitting pull requests (PRs) for open source projects on GitHub. It explains that PRs allow for streamlined code review and merging compared to older methods like patches and mailing lists. Some tips include starting with small fixes, thoroughly testing changes, asking maintainers if anything is unclear, and being mindful of timezones when communicating with contributors in other parts of the world. Rejections may occur if a PR is out of scope or breaks compatibility. Dividing large work into separate, well-documented PRs helps maintainers review and approve changes.

1. Getting Merged
All about social coding
Yo-An Lin
@c9s

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

3. The
old
school
open
source
collaboration
以往的開源協作

4. ...
are
done
by
patches
and
mailing
lists.
是靠 patch + mailing list 完
成的

5. sometimes
you
can
only
contact
the
maintainer
with
an
e-­‐mail...
有時候你甚⾄至只有 e-mail

7. ⼀一鍵寄出，⾳音訊全無

8. You
have
to
poke
戳戳樂，如果你很愛玩的話

9. 無⽌止境合併衝突

10. The
new
age
of
open
source
collaboration
新時代的開源協作

11. ..
are
done
by
pull
requests
是靠 Pull Request 來完成的

12. Introduced by GitHub in 2008/2009

13. It
combines
review,
merge,
and
social
集檢閱, 合併, 社交於⼀一⾝身

14. One Click
Merge

15. It
reduces
the
cost
of
communication
&
efforts
減少以往的溝通成本

16. How does it
work?
Pull Request
如何運作?

22. For what
reason? 發什麼 PR

23. "I
am
doing
+ine!
why
do
I
have
to
send
the
PRs?!"
我好好的，發什麼 PR ?

24. http://wowquote.tw/quote/371

25. If
you
want
to
enrich
your
CV
您的 CV 很無聊嗎?

26. Then
you
should
send
PRs
那就送 PR 吧!

27. Do
you
want
to
claim
that
you're
the
contributor
of
XXX
project?
你想要聲稱是某專案的貢獻
者

28. Then
you
should
send
PRs
那就送 PR 吧!

29. Seriously,
認真的說,

30. Once
you
merged
the
changes
to
upstream
⼀一旦可以合併本地修改到上
游

31. 1.
Reduces
the
cost
of
maintenance
1. 減少維護成本

32. 2.
Helps
you
update
bug
Nixes
from
upstream
without
pain
2. 無痛接收新的 BugFix

33. 3.
Helps
you
avoid
merge
conNlicts
for
the
future
3. 避免未來的修改衝突

34. 4.
The
document
will
be
maintained
4. 還有⼈人持續幫你維護⽂文件

35. 有這麼好康還說什麼

36. Rejected 駁回

37. Your
PR
might
be
rejected
if
...
你的 PR 有可能會遭到駁回，
如果...

38. It
doesn't
match
the
direction
of
the
project
與專案進⾏行⽅方向有衝突

39. It's
out
of
scope
或者超出範圍

40. It
will
break
the
compatibility

41. A Real World Case:

43. 遭到駁回

44. The scientific ways to send
pull requests

45. RFC First 提案與回饋

46. Ask
First,
Shoot
later
問清楚，再動⼿手

47. 先射後補也會讓⼈人尷尬

48. Nobody is
somebody 沒有⼈人就是你

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

50. Anything
can
be
included
in
a
pull
request

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

52. Don't
limit
yourself

53. Start small 從⼩小處著⼿手

54. Small
things
usually
would
get
merged
easily

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

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

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

58. Read The
Contribution
Document

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

60. If
you're
not
doing
it
right
on
the
coding
style,
you're
wasting
your
time
to
get
merged.

61. For
example,
the
golang
team
asks
you
to
run
`go
fmt`
when
everytime
you
submit
a
patch

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

63. Divide and
Conquer 分⽽而治之

64. When
you
want
to
do
something
big

65. You
should
divide
it
into
small
separated
pull
requests

66. Good
impression
helps
a
lot

67. 這是⼀一個
"最熟悉的陌⽣生⼈人"
的概念

68. Detail matters 細節

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

70. A
good
brief
helps
reviewer
quickly
understand
the
changes

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

72. To
proof
it's
author's
fault

73. Or..
to
prevent
things
like
this...

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

76. PR For Feature
• Objective
• Summary
• Effect (Or side effect)
• Tests

77. Safety 安全

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

79. It's
also
important
to
get
continuous
testing
pass

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

81. Write
down
the
side
effects
to
show
your
careful
thoughts
to
the
author

82. Just Ask 問就對了

83. Asia
people
usually
are
too
shy
to
ask

84. Sometimes
people
just
don't
write
down
their
concern
on
GitHub
有時專案作者很少會寫下⾃自
⼰己的⼼心中顧慮的部分

85. When
you
don't
get
reply,
you
should
ask

86. "If
you
have
any
concern,
please
let
me
know"
also
ping
them
back
to
reply

87. Timezone
matters 時區有差

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

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

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

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

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

93. They
have
life!

95. And
for
Asia
people,
you
can
just
poke
around,
they
will
reply
you
all
day

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

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

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

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

100. To
get
response
instantly
要得到快速回覆

101. You
should
send/reply
at
the
correct
time
你應該在正確的時間點發信

102. And
you
shall
mostly
get
the
response
quicker
then
you
thought.

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

104. First
in,
First
out

105. Last
In,
Never
Out

106. Because
they've
got
off
work

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

108. World Clock app for multi-timezone

109. Countersign 連署

110. Votes
can
show
the
need
to
the
author

112. Partnership 合作夥伴

113. By
being
reviewed
or
reviewing
PRs
from
others

114. you
will
know
good
people

115. Different
from
LinkedIn,

116. You
know
their
code
&
personality

117. Negotiation 交涉

118. Screenshot
Rocks 有圖有真相

119. Screencast
even
better!

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

122. LICEcap
https://github.com/lepht/licecap

123. Questions? 問題?