Working effectively with Pull Requests

Talk at the #devnology community day 2014

Transcript

1. Working Effectively with Pull Requests Georgios Gousios // @gousiosg! Delft University of Technology
3.    fork-edit pull request merge
10. https://www.flickr.com/photos/ginparis/6123991950/ Pull Requests are great because: Everything in one place
11. Pull Requests are great because: Tool integration and automation
12. Pull Requests are great because: Contextual information
13. 45% of all collaborative projects have used PRs
16. Large scale collaboration 5HSRVLWRU\ &RPPLWV 3XOOUHTXHVWV &RGHUHYLHZV ,VVXHV ,VVXHFRPPHQWV 7RWDO LVDDFVQSP       WRUYDOGVOLQX[       V\PIRQ\V\PIRQ\       MTXHU\MTXHU\PRELOH       MR\HQWQRGH       &RFRD3RGV6SHFV       JLWODEKTJLWODEKT       DQJXODUDQJXODUMV       UDLOVUDLOV       P[FOKRPHEUHZ       http://www.gousios.gr/blog/The-triumph-of-online-collaboration/
17. Large scale collaboration 5HSRVLWRU\ &RPPLWV 3XOOUHTXHVWV &RGHUHYLHZV ,VVXHV ,VVXHFRPPHQWV 7RWDO LVDDFVQSP       WRUYDOGVOLQX[       V\PIRQ\V\PIRQ\       MTXHU\MTXHU\PRELOH       MR\HQWQRGH       &RFRD3RGV6SHFV       JLWODEKTJLWODEKT       DQJXODUDQJXODUMV       UDLOVUDLOV       P[FOKRPHEUHZ       http://www.gousios.gr/blog/The-triumph-of-online-collaboration/ 23,501
18. GitHub Research @ TU Delft
19. GHTorrent • Query-able offline mirror of all data from the GitHub API ! • Since Feb 2012 • 5,6TB in MongoDB • 600M rows in MySQL • 1GB per hour Georgios Gousios: The GHTorrent dataset and tool suite. MSR 2013: 233-236
21. How do projects use pull requests?
22. Pull Requests Georgios Gousios, Martin Pinzger and Arie van Deursen:An exploratory study of the pull-based software development model. ICSE 2014: 345-355
23. Pull Requests are small (< 20 lines); merged in < 1 day; are briefly discussed Georgios Gousios, Martin Pinzger and Arie van Deursen:An exploratory study of the pull-based software development model. ICSE 2014: 345-355
24. Pull Requests are small (< 20 lines); merged in < 1 day; are briefly discussed are merged when they affect a hot project area Georgios Gousios, Martin Pinzger and Arie van Deursen:An exploratory study of the pull-based software development model. ICSE 2014: 345-355
25. Pull Requests are small (< 20 lines); merged in < 1 day; are briefly discussed are merged when they affect a hot project area are processed fast when project has test suite Georgios Gousios, Martin Pinzger and Arie van Deursen:An exploratory study of the pull-based software development model. ICSE 2014: 345-355
26. Pull Requests are small (< 20 lines); merged in < 1 day; are briefly discussed are merged when they affect a hot project area are processed fast when project has test suite are processed fast when contributor has good track record Georgios Gousios, Martin Pinzger and Arie van Deursen:An exploratory study of the pull-based software development model. ICSE 2014: 345-355
27. Pull Requests are small (< 20 lines); merged in < 1 day; are briefly discussed are merged when they affect a hot project area are processed fast when project has test suite are processed fast when contributor has good track record are rejected mostly due to insufficient task articulation Georgios Gousios, Martin Pinzger and Arie van Deursen:An exploratory study of the pull-based software development model. ICSE 2014: 345-355
28. How do developers use of pull requests? http://perceptionvsfact.com/ti5
29. Survey of 1,500 devs • 740 project owners, 760 contributors • 25 questions, 7 open-ended • By personal invitation to 3,400 projects Georgios Gousios, Andy Zaidman, Margaret-Anne Storey and Arie van Deursen. Work practices and Challenges in pull based development: The integrator’s perspective. Tech Report TUD-SERG-2014-13
30. What is the biggest challenge you face when working with pull requests?
31. timezones coordination among contributors coordination among integrators impact politeness asking more work bikeshedding hit 'n' run RPs poor documentation age syncing feature isolation developer availability conflicts differences in opinion motivating contributors generalizing solutions tools git knoweledge size review tools testing responsiveness maintain vision volume explaining rejection reviewing maintaining quality time rank Top Second Third Project owners
32. R509: Huge, unwieldy, complected bundles of ‘hey I added a LOT of features and fixes ALL AT ONCE!’ that are hell to review and that I’d like to *partially* reject if only the parts were in any way separable.. R42: Lack of knowledge of git from contributors; most don’t know how to resolve a merge conflict. R514: Sifting through the GitHub information flood to find what, if any, I should address. R635: I worry about alienating our valued contributors R449: Dealing with loud and trigger-happy developers.
33. roadmap traceability self contained infrastructure setup accept design changes guidelines predicting acceptance correctness fairness personal skills time code quality appreciation turtle awareness testing politics fear of rejection code review impact analysis tools desirability communication explain rationale conflicts understanding code base project compliance responsiveness rank Top Second Third Contributors
34. R98: Projects with lots of open pull requests and few actually being accepted R202: Ensuring that my pull request doesn't have unintended side effects due to not being intimately familiar with the entire code base. R711: The supercommitter issue. The code you are modifying was probably written by the gatekeeper for the pull requests. R635: Navigating through forks of an abandoned project to see if someone implemented that already. R145: Facing nazi project maintainers. R299: Cockyness
35. Project owners 1.Provide submission guidelines 2.Invest in good tests 3.Automate 4.Be reactive 5.Monitor PR performance
36. Submission Guidelines • Setting up development environment • Setting up branches • Coding style • Commit guidelines • Communication options. PRs are post-hoc communication. • Include updated list of low hanging fruit for beginners People generally expect a CONTRIBUTING.md file
37. Submission Guidelines
38. Invest in good tests • Run everything with a single command • Use tools like Vagrant to simulate environments • Measure PR coverage in CI
39. Automate • Building/CI • Quality checks • Testing • Shipping The Github API is brilliant. Take advantage of it.
41. Be reactive • Don’t allow PRs to linger • Reply to contributed requests • Close unwanted pull requests • Be there when discussion diverges from technical
42. Monitor Performance • Compare against what is expected • Average pull request merged in 1 day • Average project merges 85% of PRs • Monitor slow pull reqs • Keep track of your backlog • Monitor community engagement
43. Backlog http://ghtorrent.org/pullreq-perf/
44. Slow pull reqs http://ghtorrent.org/pullreq-perf/
45. Community engagement http://ghtorrent.org/pullreq-perf/
46. Community engagement http://ghtorrent.org/pullreq-perf/
47. Monitoring with GHTorrent http://ghtorrent.org/
48. Monitoring with GHTorrent http://ghtorrent.org/
49. Monitoring with GHTorrent http://ghtorrent.org/
50. Monitoring with GHTorrent http://ghtorrent.org/
51. Monitoring with GHTorrent http://ghtorrent.org/
52. Monitoring with GHTorrent http://ghtorrent.org/
53. Monitoring with GHTorrent http://ghtorrent.org/
54. Contributors
55. Contributors 1.Obey the guidelines (when available) 2.Invest time to learn the tools 3.Keep it short, hot and isolated
56. Owners and Contributors
57. Many problems are social
58. Many problems are social Discussion etiquette Bikeshedding Strong egos Appreciation (lack of)
59. Not like this, please! https://github.com/torvalds/linux/pull/17
60. Not like this, please! https://github.com/torvalds/linux/pull/17
61. Not like this, please! Social Interaction? https://github.com/torvalds/linux/pull/17
62. extra work prioritization i18n prior consensus roadmap traceability self contained infrastructure setup accept design changes guidelines predicting acceptance correctness fairness personal skills time code quality appreciation turtle awareness testing politics fear of rejection code review impact analysis tools desirability communication explain rationale conflicts understanding code base project compliance responsiveness 0.0 2.5 5.0 7.5 Percentage of responses rank Top Second Third What is the biggest challenge with PRs? accepting blame communicating goals and standards context switching multiple communication channels reaching consensus poor notifications project speed process ignorance timezones coordination among contributors coordination among integrators impact politeness asking more work bikeshedding hit 'n' run RPs poor documentation age syncing feature isolation developer availability conflicts differences in opinion motivating contributors generalizing solutions tools git knoweledge size review tools testing responsiveness maintain vision volume explaining rejection reviewing maintaining quality time 0.0 2.5 5.0 7.5 Percentage of responses rank Top Second Third @gousiosg