Working effectively with Pull Requests

Working effectively with Pull Requests

Talk at the #devnology community day 2014

43df3993acc9af4e9f619e59cd849aee?s=128

Georgios Gousios

October 04, 2014
Tweet

Transcript

  1. Working Effectively with Pull Requests Georgios Gousios // @gousiosg! Delft

    University of Technology
  2. None
  3.    fork-edit pull request merge

  4. None
  5. None
  6. None
  7. None
  8. None
  9. None
  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

  14. None
  15. None
  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
  20. None
  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.
  40. None
  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