Introduction:

To avoid errors and ensure you're keeping your GitHub records useful and readable, you need to know the correct way to make a pull request. This checklist will make sure the issue is properly tested (for both functionality and user experience), and also guide you through the review process.

There are some optional steps in this checklist that are designed to help passively squash low-priority bugs. Feel free to remove step 8 if you're not concerned with that, or if you want to make the process go faster. Since the PR process is run so often, it's a great place to insert small steps like this and whittle down your bug backlog.

Make sure you finished the issue

Re-read the summary and description of the issue in JIRA and make sure that you finished it.

Make sure to thoroughly test the issue

Please do not take this step lightly.

This is very important. The majority of issues that fail review are because something was not tested carefully.

Make sure that the thing you have fixed is indeed fixed.

For example, if your issue was to track a field in Intercom, then make sure that the field is actually being sent to Intercom and shows up.

Check usages of modified methods

It's possible that during code refactoring some methods were changed, we need to check their usages and make sure that logic is not broken.

1

Check usages of modified Service methods

2

Check usages of modified Repository methods

Don't forget to test on mobile for anything visual that you change

Chrome developer console has a button where you can resize the screen to the mobile size. This is a way to see if anything is looking weird.

Run all tests to make sure they're passing

Make sure the PR contains a new test

If BE: Make sure the PR removes 1 Scalastyle issue

We're trying to get rid of all Scalastyle issues, so make sure you remove one issue when making a BE PR.

To see a list of all issues, type sbt scalastyle.

Run code formatters if applicable

If it's a BE PR, then run this:

sbt fmt

If it fails, then so will CirlceCI. If it doesn't seem to be formatting correctly you can go in to the offending file and use Command-Shift-L (or Ctrl-Shift-L if not on Mac) or do sbt clean and then start over from the top.

If it's a FE PR, then run this:

grunt lint

Fix any errors (if you don't, CircleCI will squawk).This will run a javascript linter, and also a SCSS linter.

SCSS Guidelines:

Make sure there is a namespace for each new scss file:

ex:.feature { .feature-component {

}}

Make sure the class is saying what the element does vs. using another class because you already have it (Make it semantic).