Its time for PullRequests 2.0

talk title:

How to Create a Good Pull Request — and How to Review One?
(can also be called as)
Its time for PullRequest 2.0
(can also be called as)
Is Pull Request really a thing?

description:

The first thing I do at work every day 📈 is to review all open pull requests. Likewise, I try to open ☑️ a pull request before I complete my day. One day I asked myself, am I doing both in the correct way? And PR really benefits me.

Like starting from what is a pull request?
Why and When do I have to create one?
What are the points I should remember when I am creating a PR?
How to draft the description?
How to raise a conversation and how to answer one?

And I understood many factors answering the above and practised them continuously. This talk will share my experience on these points and the answers I found for the above questions with a clear demo.

Transcript

1. It’s TIME for PRs 2.0 Muralidharan Kathiresan
2. What’s in for today? ✔ What are Pull Requests? ✔ PRs - Real life example & Developer Scenario ✔ Problems faced around PRs ✔ How to create a perfect pull request? ✔ How to review a pull request like a pro? ✔ Automate the Chores ✔ What’s next?
3. Pull Requests Recipe Book Friends Recipe 3 Recipe 2 Recipe 1 Git request-pull [-p] <start> <url> [<end>] Review Recipes Share Recipes Add to Book Recipes
4. Pull Requests Recipe Book Friends Recipe 3 Recipe 2 Recipe 1 Git request-pull [-p] <start> <url> [<end>] Review Recipes Share Recipes Add to Book Recipes
5. Pull Requests Recipe Book Friends Recipe 3 Recipe 2 Recipe 1 Git request-pull [-p] <start> <url> [<end>] Review Recipes Share Recipes Add to Book Recipes Repository Code Merge Code Review Pull Request Features/Code Developers
6. Why code review? 00 04 08 12 16 20 Code Reviews Tools Testing Management Code Style &
 Standards Research 
 Design, Etc Automate Others
7. Why getting a PR reviewed is always tough?
8. Long waiting
9. One after one review
10. Prolong/delayed response in conversations Author Reviewers
11. Pressure to get merged soon
12. Why reviewing a PR is tough?
13. Can’t f igure out what’s happening Programmers while reviewing the codes
14. Too Big
15. Tough to f ind time
16. How can we get rid of these?
17. Proper commit history
18. Proper commit history
19. Create Small PRs
20. Why size is important Average PR time by Pull Request size PRs under 200 diff size get merged twice as fast
21. Why size is important PRs under 15 minute review time get picked up 20x faster Average Pull request pick-up time
22. Provide proper information about the PR
23. Provide proper information about the PR
24. PR templates
25. Be your own reviewer
26. 26 Respond to Reviews Quickly
27. 27 Understand the context
28. 28 Don’t feel the pressure to approve
29. 29 Don’t be afraid to ask “why?”
30. 30 Don’t be afraid to add pedantic comments
31. 31 Review as many PRs as you can
32. 32 Keep your own checklist for approval
33. 33 How does a checklist looks? ✔ Are the tests cases covered and passed? ✔ Do the changes follow de f ined architecture? ✔ Can it be simpli f ied to a better version? ✔ Is the code modular/clear and easily understandable? ✔ Do it follows SRP and other coding principles?
34. 34 Automate the chores
35. 35 Danger https://github.com/danger/danger
36. 36 Last things… ✔ Avoid being too serious ✔ Respect everyone’s preference ✔ Never make the process personal ✔ Add constructive feedback ✔ Teach, don’t just tell
37. 37 ✔ Be the change ✔ Talk to your lead / manager ✔ Talk to your team ✔ Propose this one "crazy idea" Now what?
38. 38 Twitter Blog