Pull requests

Introduction

Git flow

Code review

## Why do code review?

<ul>
							<li class="fragment fade-in">To share knowledge</li>
							<li class="fragment fade-in">To create familiarity with the code base inside a team</li>
							<li class="fragment fade-in">To improve code reproducibility and transferrability</li>
							<li class="fragment fade-in">For some peace of mind</li>
							<li class="fragment fade-in">To catch bugs</li>
						</ul>

Note:
						- Learn by reading other people's code
						- You will need to create a reproducibility package at the end of a project or to hand it over. Reviewing code periodically is a way to make sure this is not an overwhelming task
						- RPs are often the only person looking at the code for a project, which can be a lot of responsibility
						- Mention some horror stories 
						- It may seem like a very time-consuming task, but it will save you time in the long run, specially if you do it often
						---
						## How to do code review using GitHub?

<ul class="small">
							<li><a href="https://github.com/DevInnovationLab/dil-template-repo/blob/main/CONTRIBUTING.md#workflow">Suggested workflow for DIL projects</a></li>
							<ol>
								<li>Open a feature branch for small(ish) task</li>
								<li>Merge feature branches to develop every one or two weeks</li>
								<li>Merge develop to master at big project milestones, such as those used to create the results in reports, presentations, working papers, or paper submissions</li>
							</ol>
							<li><a href="https://devinnovationlab.github.io/guides/templates/code-review.html">What to look for when reviewing code</a></li>
							<li><a href="https://github.com/thoughtbot/guides/tree/main/code-review">A code of conduct for code review</a></li>
						</ul>

Note:
						-  Once the work on a feature branch is done: update the README, open a pull request to `develop`, and run the code for the entire project with the changes
						- Open pull requests to `main` to store major versions of the code, such as those used to create the results in reports, presentations, working papers, or paper submissions

Pull requests (PRs)

## Opening a pull request (author)

1. On the browser, click on Pull requests > New pull request
						1. Select your feature (`develop`) branch as the `compare` branch and `develop` (`main`) and the base branch
						1. Review your changes
						1. Give a self-explanatory title to your pull request
						1. Write a longer description of the changes made (if there are a lot of them) and why they are important
						1. Add a reviewer to the pull request
						1. Create the pull request
						---
						## Reviewing a pull request (reviewer)

1. Read the author's notes
						1. Go to the *Files changed* tab and read the changes made
						1. Click on the `+` sign next to a line to add comments to it (drag to comment multiple lines)
						1. Click on the first icon to the left to make direct content suggetions
						1. Explore the other formatting and linking options on the dialog box
						1. Click on the *Viewed* box next to a file's title to hide changes
						1. When you are done reviewing the changes, go to the top of the page and click on *Review changes*
						1. Select approve changes or request additional changes
						1. Leave a comment explaining your decision
						---
						## Responding to a review (author)

1. Open the PR from the *Pull request* tab in the repo's main menu
						1. Respond to reviewer's comments using the same dialog box features
						1. Direct code suggestions can be committed from the *Conversation tab*
						1. If a comment had no action points, mark the conversation as resolved after reading it

Note:
						show how to link to commits
						---
						## Reviewing author's responses (reviewer)

1. Open the PR from the *Pull request* tab in the repo's main menu
						1. Respond to author's comments using the same dialog box features
						1. If you are satisfied with the responses to a conversation, mark it as resolved
						1. If all conversations are resolved, accept the changes and merge the PR
						
						Note:
						if there are open conversations, repeat the cycle

Introduction

Git flow

Code review

Pull requests (PRs)

Let's try this!