If you want to understand a new project, or grow your skills faster in a project your already working in, doing code reviews can be one of the fastest ways to improve your skills. Doing code reviews provides the opportunity to interact with people already familiar with the code base, ask questions, and learn. Not only is this good for your personal growth, the community needs more reviewers to remain healthy. We will look at the metrics, and selected anecdotes, to demonstrate the community need.

1. Michael Strack

2. Open Source Code Reviews
Building sustainable data analytics tools
w/
@holdenkarau
Convincing
you to do my
job for free!
Melinda
Seckington

3. Holden:
● My name is Holden Karau
● My pronouns are she/her
● Apache Spark PMC, Contributor to many others
● co-author of Learning Spark & High Performance Spark
● Twitter: @holdenkarau
● Slideshare http://www.slideshare.net/hkarau
● Code review livestreams: https://www.twitch.tv/holdenkarau /
https://www.youtube.com/user/holdenkarau
● Spark Talk Videos http://bit.ly/holdenSparkVideos
● Feedback (if you are so inclined): http://bit.ly/holdenTalkFeedback

5. What is going to be covered:
● What you can get from participating in open source code reviews
● Why the community needs your help with open source reviews
● How to find a good PR to review
● Some classes comments you can make early on (without lots of project
experience)
● Some communication pointers (the internet can be scary!)
● An optional exercise time: pair up with someone and do a review
Andrew

6. Who I think you wonderful humans are?
● Nice* people
● Want to grow your career
● Want to make open data analytics more sustainable
● Waiting for one of the other tracks to start/the coffee to kick in

8. Open Source Code reviews are a like
Mermaid School
1. You can do both in many places in the world
2. They help you grow your skills
3. Build on your existings skills (e.g. swimming or Python)
4. You get better with time but need to start somewhere
5. People don't always understand how they help you grow
your skills and don't want to pay for it*
6. Coffee makes it better

9. Benefits to you get from OSS reviews
● Grow skills
● See the world*
● Faster recognition
● Deeper integration in community
● The ability to contribute with fixed amounts of time
*Of open source & maybe the real world

10. See more of the world
● Starter issues are often designed to only touch a few
things
● Even moving beyond starter issues, there’s only so
many hours in the day and you can’t write everything
● Helps you can a better understanding of the project as a
whole
● Let's you take skills between projects faster
○ Know what good Python looks like? Great, many projects need help
with that
Vania Rivalta

11. Possible Faster Recognition
● General more contributors than reviewers
● Reviewers stand out
● Reviews can be the difference between a contributor
and someone trusted to make their own changes to the
project
● Allows you to work with more people
Sham Hardy

12. Easier to control your time
● Getting code into large OSS projects can take lots of
time
● Want to contribute a new PR? You will often need to
shepard a PR for an extended period of time
● “One more bug”
● With reviews: do what you can, but you don’t have to be
continuously responding to provide value
Rob Hill

13. Why the community needs you?
● Many projects suffer from maintainer burn out
○ Some of this comes from the pressure to review too much code
● Many projects are limited by reviewers not coding
○ Spark has > 500 open PRs
● More diverse reviewers: more diverse solutions
● Experienced reviewers become blind to “the way it’s
always been done”
● Represent the user(s)
Jerry Lai

14. 2018 top 25 projects with most opened PRs
by unique authors

15. Rate of PRs / Reviews

16. Yes especially "successful" projects
Barbara Doduk

17. Yes especially "successful" projects

18. Live OSS Code Review Demo
● Additional: Live reviews on my YouTube if you want
https://www.youtube.com/user/holdenkarau

19. What makes an OSS review different?
● Higher chance you don’t know and haven’t met the folks
● Often more diversity level of language comfortability
● Less shared assumptions
● Really hard to walk over and apologize/buy coffee
● Sometimes strangers + the internet == assholes
○ Try not to be an asshole, but also look for how the project deals with
assholes
● Sometimes more competing goals/visions

20. New reviewers: a special value
● You can “see the onion” or the weird things everyone is
used to
● You can call out parts of the code which, while they may
make sense to the person who wrote it don’t in general
● You have different notions of how the software is used
● You can be less intimidating (if you want)
● You don’t assume how something works, so you’ll go
check and maybe find out it’s different

21. Getting started:
● Pick a project
● Get familiar with the projects tools
● Get familiar with the people & how they communicate
● Finding a good first PR to review
Roland Turner

22. Picking a project:
● It works better if it’s something you use in a language
you understand
● Ideally one which needs review help (are there lots of
inbound PRs or PRs that no one has the time for)?
● Is the project friendly: go check the mailing list or slack
or w/e and see how folks are
Chris Parker

24. Getting Familiar with the project tools:
● CI/CD (travis, jenkins, circleci, etc.)
● Find the integration tests (if any)
● Version control: figure out how to see who’s worked on
a file in the past (git blame & git log -p are two of my
friends)
● Find the projects issue tracking system
● Find the mailing lists
● Figure out how to build from a PR or a branch
easegill

25. Get familiar with how the project communicates
● Look at other PRs reviewed, accepted and rejected
● Look at the mailing list for tone and style
● Look to see how they respond to newcomers -- you
might want to pick another project based on this
○ For example I might not choose the Linux Kernel as a place to try this

26. Finding a good first PR to review
● Smaller PRs can be better
● Something you care about
● Often easier to be one of the early reviewers so if it’s
late stage stay away from

27. Doing that first review:
● Feel free to leave comments like
○ “I’m new to the project reading this I think it’s intention is X is that
correct? Maybe we could add a comment here”
○ Look for when changes are getting out of sync with docs “Can we
update the docs or create a follow up issue to do that?”
○ Style: Is there a style guide? Does this follow it? Does this follow
general “good” style?
○ Building: Does this build on your platform?
○ Look around for duplicated logic elsewhere in the codebase
○ Find the original author and ping them to take a look
● Get your IDE set up and jump to definition a lot
● Be prepared to look at the libraries documentation

28. Communicate carefully please
● The internet is scary enough
● “This sucks” can be heartbreaking
● You don’t know how much time someone put in
● Make it clear you are new to the project (gives you
some more leeway) & sets expectations
● Understand folks can get defensive about designs:
sometimes it’s not worth the argument
● People are allowed to be wrong on the internet
● It’s ok to be scared
Ivan

29. Phrasing matters a lot
● This is slow
● This is hard to
understand
● This library sucks
● No one would ever use
this
● You're using this wrong
● Could we do this faster?
● I'm confused, is it doing X
& could we add a
comment?
● Have you looked at X?
● What's the usage
pattern?
● X has problem Y, how
about Z?

30. Some articles on good code reviews (internal focus):
● https://smartbear.com/learn/code-review/best-practices-fo
r-peer-code-review/
● https://medium.com/palantir/code-review-best-practices-19
e02780015f
● https://dev.to/codemouse92/10-principles-of-a-good-code-r
eview-2eg
● https://blog.digitalocean.com/how-to-conduct-effective-co
de-reviews/
● https://hackernoon.com/how-to-give-and-get-better-code-re
views-e011c3cda55e
● https://mtlynch.io/human-code-reviews-1/

31. At a break you can do this!
● Don't want to go alone? You can do this as a group
● Raise your hand if you want to go do this after
● Try and pair with someone with different experience

32. High Performance Spark!
Available today, not in anyway related to this topic.
Cat’s love it!
Amazon sells it: http://bit.ly/hkHighPerfSpark :D

33. Random:
https://haute.codes
Generate clothing items from code
Including dresses with pockets

34. Sign up for the mailing list @
http://www.distributedcomputing4kids.com

35. Cat photo by Jean-Simon Asselin
Thank you!