IntroductionCollaborative Construction
Figure 1
What is being reviewed can also change what
the collaborative construction is called. When reviewing single lines of
code as they are written, this is usually called pair programming.
Reviewing single PRs or commits is classified as code review. You can
also review design documents in project planning. Checking test coverage
may be called quality assurance and a final check of a repository prior
to release is a repository review. 
Figure 2
When a review takes place is tightly
coupled to what is being reviewed, but not entirely. Consider discussing
a change to the underlying data structure in a program. Such a
recommendation could be easily considered during design but may be
impractical prior to release (especially if the code isn’t modular).
Keep in mind where in the project life cycle a review takes place. 
Pair ProgrammingIntroduction to Pair Programming
Figure 1
Originating from a story in the 1999 book, The Pragmatic Programmer,
“rubber-ducking” is the act of describing code line-by-line to
something, sentient or otherwise (a rubber duck in the original story),
while debugging code. While it may sound ridiculous, this phenomena has
been found to increase the detection of bugs or unintended behavior.
While pair-programming, the driver will explain the code line by line
while substituting the rubber-duck for the navigator, experiencing a
similar effect. 
Figure 2
Pair Programming Activity
Code Reviews
Figure 1
Best Practices
Code Review Activity
Figure 1
You don’t have to perform code reviews in github, but they are nicely
integrated and widely used so it is helpful to practice there. Ideally,
your project would develop in the following cycle: 
1. A
user requests a feature or notices a bug. They open an
issue. Each issue should contain a single problem or
feature and be self contained. 2. A developer works on the issue,
implementing the feature or fixing the bug. The submit a pull
request consisting of (possibly several) small commits. Commits
should be atomic, e.g. can be selected and applied in any order. 3. A
maintainer or other developer reviews the pull request.
They should ensure the PR addresses the issue (and only the issue) while
maintaining a high quality of code in the project.