Skip to content

Opening Pull Requests

Contents:

1. Check out a New Branch for the Work to be Completed

Branch Naming Guidelines

Note

Please also refer to our commit conventions as branch naming conventions align closely with commit guidelines.

When creating a branch, follow the guidelines below:

  1. Type:

    The following are the acceptable types:

    • feat: For new features
    • fix: For bug fixes
    • chore: For general maintenance tasks
    • docs: For documentation changes

  2. JIRA Ticket Number:

    • Always include the associated ticket number, e.g., rp-1250.

  3. Short Description:

    • Use kebab-case (e.g., archive-icon-update) for a concise description of the work being done.

Examples

  • feat/rp-1250-phone-warning
  • fix/rp-1261-archive-icon-update
  • chore/rp-1300-refactor-auth-module

This standardization ensures clarity and consistency across all branch names.

2. Complete the development work

Be sure to follow the commit guidelines throughout this process.

3. PR Submission Checklist

Prior to submitting a PR, be sure to check the following items:

Ensure Jira ticket is updated with correct testing instructions

If there have been any deviations from the original Jira ticket, make sure the testing instructions have been updated appropriately. This helps the person testing the functionality / reviewing the PR to make sure everything is working as expected.

Ensure your work satisfies all business rules from the Jira ticket

Functionally test your work before submitting a PR. If there are obvious regression bugs / deviations in functionality from the ticket, those should be resolved prior to submitting a PR.

If another unrelated bug is identified, open a new ticket describing the bug and link it to the current ticket.

Tidy up any unused console.log() or Console.WriteLine() type statements

There are very few circumstances in which these statements should be included in the codebase - e.g. when logging basic authentication steps in an app to let us know that authentication has taken place. These statements overall clutter up the console unnecessarily.

Tidy up any commented code

Commented code should be removed prior to a PR, as it clutters the file in general.

There are some circumstances in which there's a specific reason for keeping commented code - in those cases, the reason should be commented along with it so a future reader is aware of why this was left behind. E.g.:

// TODO - the following code will need to be enabled at some point, but we are
// consciously leaving this out for now

// const foo = getSomeValue();
// doSomethingElse(foo);

Tidy up verbose logging statements, etc.

E.g. Angular has an enableTracing configuration option for the Angular Router. This is helpful for debugging by logging verbose Router details, but should not be included in the main codebase.

Ensure your work follows the code style guidelines

Check the General Code Style Guidelines and language-specific code style guidelines to make sure your work follows these guidelines.

4. Open the PR on Github

It's time to open a PR. This can be done either from the GitHub web interface OR from the GH CLI:

gh pr create

# Follow prompts

PR Naming Convention

The PR name should include the conventional commit prefix, the ticket number, and a brief description of the branch:

<commit_prefix>/<Jira_ticket_number>: <description>

Examples might include:

fix/RP-1234: Fixes issue where dashboard throws error when not authenticated

feat/RP-4321: Adds Refresh button to reports inbox

docs/RP-2233: Adds docs for user sync process

5. Reassign & Notify

PR Assignment

PR Assignment is critical! If a PR is not assigned to the right person(s), it can and will be missed.

There are 2 actions to take here:

  1. Mark the appropriate developer(s) as a reviewer on the PR
  2. Assign the PR to the same developer(s).

For example:

Example PR assignment