PR reviews are crucial for maintaining code quality, ensuring best practices are followed and fostering collaboration within a development team. They provide an opportunity for developers to get feedback on their code from their peers before merging it into the main codebase, helping to catch potential bugs, stylistic inconsistencies, and architectural issues early on. In addition, PR reviews help to cross-train devs on projects they don’t work on day-to-day, thus providing more coverage to our clients. 

Benchmarks

We are setting standard turnaround times for PR reviews to ensure that they are completed in a timely manner for our clients. However, this must be balanced with the developers' need for uninterrupted work time where they are not pulled away to review PRs constantly. 

• For standard tickets/asks - PRs reviewed within 24 hours

• For important tickets/asks - PRs reviewed within 3 hours or before end of business day

• For critical tickets/asks - no PR review, unless dev is unsure of the fix

As some clients tend to mark tickets as “IMPORTANT” or “CRITICAL” when they might not be.  Megan or Wes will review these tickets and adjust the severity if necessary. 

Tasks are defined as “CRITICAL” if:

• A website is not loading for multiple users

• A website is loading, but it’s showing an error instead of content or the content is significantly malformed or out of place

• A website appears to have been defaced/hacked in some manner  

• There are any urgent security-related issues

PR “Pairs”

Each client website currently has a minimum of one main developer, with a few having two. Each site will be matched with a second developer who will review PRs.

Github Pull Request Review Process

This proces below outlines the standard Github pull request (PR) review process for developers, detailing the steps involved for both the requesting developer and the reviewing developer to ensure efficient code collaboration and quality.

Definitions

• Feature Branch: A separate line of development in a version control system (like Git) used to isolate new features or bug fixes from the main codebase until they are ready to be merged.

• Remote Github Repo (Repository): A version of your project's code stored on Github's servers, accessible to all collaborators.

• PR (Pull Request): A mechanism in Github for developers to notify team members that they have completed a feature and want to merge their changes from one branch (e.g., a feature branch) into another (e.g., the main branch). It also provides a platform for code review and discussion.

The Process

1. Requesting Dev

   1. Commit local changes to feature branch and push to remote Github repo

   2. On repo page, click on “Compare & pull request”

   3. On the “Open a pull request” page, provide a clear and concise title, and a detailed description. A well-crafted title and description are crucial for effective reviews. The description should clearly state the problem being solved, the changes made, and any relevant context or links to associated issues.

   4. Request review by clicking on the gear icon beside the “Reviewers” and typing in dev username

   5. Click on “Create pull request”

   6. The requested reviewer should receive an email notification to review the pull request. Alternatively, share the URL of the pull request to the appropriate person. It's often helpful to also notify the reviewer via chat or another communication channel to ensure timely review.
      
      

2. Reviewing Dev

   1. If there are no issues

      1. Approve the request

      2. Merge and close the request (optional for Reviewing Dev)

   2. If there are issues with the PR, notify requesting dev to apply fixes

      1. Keep the current review open and

      2. Inform Requesting Dev of this issues

      3. Ask Requesting Dev to resolve issues

      4. Requesting Dev fixes issues and repeats step 1.1 and 1.6 until Reviewing Dev approves the PR.