Pull Requests

Before a pull request is submitted

CI Tasks

Any time code changes are committed and pushed to the repository, a few CI tasks will run.

• Unit tests and code coverage
• Dangerfile for miscellaneous code and feature branch inspection
• Various types of code linters

If any of the CI tasks fail, please fix them before requesting a code review.

Developer checklist

• Verify that the origin of the feature branch is dev/develop
• All files adhere to coding standards
• All files have an associated unit test with 100% code coverage
• A changelog entry is added describing the work completed
• review your own code before asking someone else to

Submitting a pull request

You can read instructions on how to create a pull request in GitHub via their help section.

While creating a pull request

1. Add a proper description

   The description should contain

   • Description of the work completed
   • Pivotal tracker url
   • Any notes that the reviewer should know before they review your code

   Example description:

   ## Description
   
   Added some neat stuff that does some other neat stuff.
   
   ## Pivotal Tracker
   
   https://www.pivotaltracker.com/story/show/123456789
   
   ## Notes
   
   Here is some info you might find useful as a reviewer.
   
   

2. Reviewers and Assignee

   • Add one or more reviewers to your pull request
     • A pull request cannot be merged until one person has approved it
   • Assign yourself the pull request

Developer Flow

1. Before a code review

   Pivotal tracker

   • On the associated ticket, click Finish

   Github

   • When your pull request is ready for code review, add the label: Ready for Review

2. During a code review

   When the pull request is being reviewed, a reviewer will:

   • Remove the label Ready for Review
   • Add the label In Review

3. Code review that requires changes

   If a pull request requires changes, the reviewer will:

   • Add the label: WIP
   • Leave detailed descriptions as to what changes need to be made and why
   • Once the changes are made, the WIP label can be removed
   • The reviewers should be notified that the code can be reviewed again

4. Successful code review

   If a code review is successful, the reviewer will:

   • Remove the In Review label
   • Add the label Ready to Merge

5. After the code review

   Github

   • The pull request is merged
   • The feature branch is deleted

   Pivotal tracker

   • On the associated ticket, click Deliver