Successfully reported this slideshow.
Your SlideShare is downloading. ×

How to contribute to an open source project and don’t die during the Code Review

Loading in …3
×

Check these out next

1 of 12 Ad
1 of 12 Ad

How to contribute to an open source project and don’t die during the Code Review

Download to read offline

Reviewing changes is an essential part of the software development. This process involves the collaboration of several team members who ensure to keep quality standards. In open source projects, the process can be overwhelming for newbies. Along this presentation, I will share experiences and best practices acquired a long of my years contributing to different open source projects, like OpenStack, Kubernetes, CNCF and OPNFV and how to improve that collaboration between contributors and reviewers.

Reviewing changes is an essential part of the software development. This process involves the collaboration of several team members who ensure to keep quality standards. In open source projects, the process can be overwhelming for newbies. Along this presentation, I will share experiences and best practices acquired a long of my years contributing to different open source projects, like OpenStack, Kubernetes, CNCF and OPNFV and how to improve that collaboration between contributors and reviewers.

Advertisement
Advertisement

More Related Content

Slideshows for you (19)

Advertisement

How to contribute to an open source project and don’t die during the Code Review

  1. 1. How to contribute to an open source project and don’t die during the Code Review Victor Morales @electrocucaracha
  2. 2. Victor Morales • +15 yrs as a Software Engineer • .NET, Java, python, Go programmer • OpenStack, OPNFV, ONAP and CNCF contributor. https://about.me/electrocucaracha
  3. 3. What is a Code Review? “A software quality assurance activity in which one or several people check a program mainly by viewing and reading parts of its source code, and they do so after implementation or as an interruption of implementation.” - Wikipedia https://www.flickr.com/photos/30478819@N08/45977680015
  4. 4. ConRev http://dev2ops.org/2010/02/what-is-devops/ DevOps Contributor Reviewer
  5. 5. Contributor 1. Review your own code first • Run Tests locally • Ensure there is no typos 2. Narrowly scope changes • No more than 300–400 lines of code • Break up large changelists with good description • https://www.conventionalcommits.org/en/v1.0.0/#su mmary • https://google.github.io/eng- practices/review/developer/cl-descriptions.html • https://wiki.openstack.org/wiki/GitCommitMessages https://www.flickr.com/photos/18378305@N00/12623408743
  6. 6. Contributor(cont.) 3. Respond graciously to critiques • Be patient when your reviewer is wrong • Communicate your responses explicitly 4. Answer questions with the code itself 5. Minimize lag between rounds of review • The code review has a higher priority than the development task to avoid long- lived pull requests. https://www.flickr.com/photos/7321654@N03/3456375365
  7. 7. Choosing Reviewer The best reviewer is the person who will be able to give you the most thorough and correct review for the piece of code you are writing. This usually means the owner(s) of the code, who may or may not be the people in the OWNERS file. Sometimes this means asking different people to review different parts of the CL. Automation scripts need to run successfully in order to pass review https://www.flickr.com/photos/49503047029@N01/246595786
  8. 8. Things Reviewers consider during the code review • Is the code well-designed and appropriate for your system? • Does the code behave as the author likely intended? • Is the way the code behaves good for its users? • Could the code be made simpler? • Would another developer be able to easily understand and use this code when they come across it in the future? • Does the code have correct and well-designed automated tests? • Did the developer choose clear names for variables, classes, methods, etc.? • Are the comments clear and useful? • Does the code follow our style guides? • Did the developer also update relevant documentation? https://www.flickr.com/photos/66757486@N00/2380987996
  9. 9. Reviewer 1. Clearly understands the acceptance criteria of the code. • Reviews the code against the code review checklist (CONTRIBUTING.md) 2. Each commit should be reviewed by at least one or two team members before pushing the code to the main branch. 3. Avoid to leave unclear comments to the author. https://www.flickr.com/photos/49968232@N00/13421955434
  10. 10. Reviewer (cont.) 4. Automate the easy stuff (linting, spelling, labeling, etc.) • Linting (Hard-Coded Values. Often indicate hasty development) - https://github.com/github/super-linter • Spelling (Typos and Bad Formatting. Reflect carelessness, cause frustration, and damage reputation) - https://github.com/reviewdog/action-misspell https://pypi.org/project/pyspelling/ • Triage - https://github.com/actions/labeler https://docs.pullapprove.com/ • Test Coverage threshold. https://coverage.readthedocs.io/en/coverage- 5.5/cmd.html?highlight=--fail-under#reporting https://www.flickr.com/photos/78205255@N00/96887547
  11. 11. The golden rule: Time is money • Reviewer’s time • Contributor’s time • CI’s time https://www.flickr.com/photos/38451115@N04/3992935923
  12. 12. Thanks

Editor's Notes

  • https://google.github.io/eng-practices/review/

    We found no evidence for the delayed issue effect; i.e. the effort to resolve issues in a later phase was not consistently or substantially greater than when issues were resolved soon after their introduction. https://arxiv.org/pdf/1609.04886.pdf
  • https://mtlynch.io/code-review-love/
  • https://mtlynch.io/code-review-love/
  • The best reviewer is the person who will be able to give you the most thorough and correct review for the piece of code you are writing. This usually means the owner(s) of the code, who may or may not be the people in the OWNERS file. Sometimes this means asking different people to review different parts of the CL.

×