Get Your Patch Accepted

Code reviews and how to survive them (from Froscon 2015)

Transcript

1. How to get your patch accepted Lorna Mitchell, August 2015
2. maintainer and team lead
3. unsolicited advice
4. stories
5. 3 ingredients
6. code
7. words
8. perspective
9. what does it do?
10. feature/bug
11. ticket(s)?
12. If there aren't any acceptance criteria for your patch, invent some
13. all the code
14. git diff master
15. git diff master...HEAD
16. tools
17. TOO BIG
18. common code mistakes
19. exotic code, no comments
20. Leaving commented code in your codebase is like leaving litter on a campsite
21. variable named $x
22. contributing.md
23. can you break your code?
24. I can
25. missing data
26. permissions
27. user is an idiot
28. tests
29. coding standards
30. syntax check
31. The commit history in your branch will be part of my project until the end of time
32. git reset --soft $(git merge-base master HEAD)
33. more info than diff
34. accurate
35. sane format
36. http://chris.beams.io/posts/git-commit/
37. SFW
38. apologies
39. will it merge?
40. git merge --no-commit --no-ff feature git merge --abort
41. fix it
42. rebase
43. A pull request is the opening line in a conversation about a feature
44. source/target
45. diff
46. title
47. description
48. what does it do?
49. what will I observe?
50. why do I care?
51. code review
52. "review" vs "merge"
53. anyone
54. peer review vs gatekeepers
55. key skills
56. Being able to see what you're NOT looking at is a reviewer's superpower
57. documentation
58. tests
59. database patch
60. deployability
61. template
62. email
63. report
64. monitoring
65. cron job
66. and if not ...
67. reject
68. automated build
69. constructive feedback
70. colleagues vs contributors
71. too much feedback
72. sandwich technique
73. harsh feedback
74. Pull requests have a lifecycle, be prepared to champion them to the end
75. 3 ingredients
76. code
77. words
78. perspective
79. Thankyou http://lornajane.net (also speaking about PHP7 tomorrow)