Day 51

September 12, 2018 17:08 UTC Team Barcelona Duo (Exercism) [2018]Subscribe to this teams's activities

The anatomy of a great pull request

We spent the day working on issue#29. We had a meeting with our coach Maikha this morning to brainstorm how to break this issue into smaller components. We are learning that having the capacity to break a problem into smaller pieces is an important skill that you need to cultivate and refine to be a good developer.

We spent the morning trying to understand how actions written in the controller are used to render data on to a view. In the afternoon we had a session with our coach Jorge to review what we learned in the morning. After our meeting with Jorge, we realized that in order to render data on to a view, we need to understand how to retrieve objects from the database using ActiveRecord. Tomorrow we will spend some time looking at ActiveRecord's finder methods and we will also look for hints to see how some of these finder methods are already implemented in the codebase.

We received some excellent feedback from our mentor Katrina on a PR that we recently submitted. We wanted to share a few of the points she made with the whole community because they are important points that we all need to keep in mind.

  • Make it easy for people to review your PR.
  • If you submit a PR with hundreds of lines of code, chances are the maintainer will push your PR to the bottom of the pile. If your PR is large, a good tip is to break it up into smaller pieces that can be submitted independently.
  • Make sure that you provide all of the relevant context that is needed for your PR. Be meticulous with providing links to previous commits, adding links to relevant documentation, and providing the context that is necessary for the maintainer to understand the feature you are trying to add, or the problem you are trying to fix. Often times we assume that people have the relevant context, but in open source projects, with hundreds of contributors we need to make sure that our steps are clearly outlined. A maintainer needs to know the purpose of the pull request, the problem that is being solved, and the steps that you took to solve the issue.
  • All of these steps take an extra 5 minutes, but taking the time will make a big difference for the maintainer and for the entire community that is contributing to the project.

We also wanted to share a video that Katrina shared with us on the anatomy of a great pull request. Getting your PR merged into an open source project is really hard. We have talked to people who have told us that they worked on a feature for days that never got implemented. This video outlines tips that you need to keep in mind so that your PR has the chance of getting merged. It helps you think about the things you need to consider when making a change, and it gives insight into the thought process that a maintainer goes through when accepting a change. It's really worth watching.


You must be logged in to add a comment.