Tweet
Tweet

Slide 1

Slide 1 text

Working Effectively with Pull Requests Georgios Gousios // @gousiosg! Delft University of Technology

Slide 2

Slide 2 text

No content

Slide 3

Slide 3 text

   fork-edit pull request merge

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

No content

Slide 10

Slide 10 text

https://www.flickr.com/photos/ginparis/6123991950/ Pull Requests are great because: Everything in one place

Slide 11

Slide 11 text

Pull Requests are great because: Tool integration and automation

Slide 12

Slide 12 text

Pull Requests are great because: Contextual information

Slide 13

Slide 13 text

45% of all collaborative projects have used PRs

Slide 14

Slide 14 text

No content

Slide 15

Slide 15 text

No content

Slide 16

Slide 16 text

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/

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

GitHub Research @ TU Delft

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

No content

Slide 21

Slide 21 text

How do projects use pull requests?

Slide 22

Slide 22 text

Pull Requests Georgios Gousios, Martin Pinzger and Arie van Deursen:An exploratory study of the pull-based software development model. ICSE 2014: 345-355

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

How do developers use of pull requests? http://perceptionvsfact.com/ti5

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

What is the biggest challenge you face when working with pull requests?

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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.

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

Project owners 1.Provide submission guidelines 2.Invest in good tests 3.Automate 4.Be reactive 5.Monitor PR performance

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

Submission Guidelines

Slide 38

Slide 38 text

Invest in good tests • Run everything with a single command • Use tools like Vagrant to simulate environments • Measure PR coverage in CI

Slide 39

Slide 39 text

Automate • Building/CI • Quality checks • Testing • Shipping The Github API is brilliant. Take advantage of it.

Slide 40

Slide 40 text

No content

Slide 41

Slide 41 text

Be reactive • Don’t allow PRs to linger • Reply to contributed requests • Close unwanted pull requests • Be there when discussion diverges from technical

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

Backlog http://ghtorrent.org/pullreq-perf/

Slide 44

Slide 44 text

Slow pull reqs http://ghtorrent.org/pullreq-perf/

Slide 45

Slide 45 text

Community engagement http://ghtorrent.org/pullreq-perf/

Slide 46

Slide 46 text

Community engagement http://ghtorrent.org/pullreq-perf/

Slide 47

Slide 47 text

Monitoring with GHTorrent http://ghtorrent.org/

Slide 48

Slide 48 text

Monitoring with GHTorrent http://ghtorrent.org/

Slide 49

Slide 49 text

Monitoring with GHTorrent http://ghtorrent.org/

Slide 50

Slide 50 text

Monitoring with GHTorrent http://ghtorrent.org/

Slide 51

Slide 51 text

Monitoring with GHTorrent http://ghtorrent.org/

Slide 52

Slide 52 text

Monitoring with GHTorrent http://ghtorrent.org/

Slide 53

Slide 53 text

Monitoring with GHTorrent http://ghtorrent.org/

Slide 54

Slide 54 text

Contributors

Slide 55

Slide 55 text

Contributors 1.Obey the guidelines (when available) 2.Invest time to learn the tools 3.Keep it short, hot and isolated

Slide 56

Slide 56 text

Owners and Contributors

Slide 57

Slide 57 text

Many problems are social

Slide 58

Slide 58 text

Many problems are social Discussion etiquette Bikeshedding Strong egos Appreciation (lack of)

Slide 59

Slide 59 text

Not like this, please! https://github.com/torvalds/linux/pull/17

Slide 60

Slide 60 text

Not like this, please! https://github.com/torvalds/linux/pull/17

Slide 61

Slide 61 text

Not like this, please! Social Interaction? https://github.com/torvalds/linux/pull/17

Slide 62

Slide 62 text

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