Code Review

All PRs must be reviewed by a teammate before they are eligable to be merged into the master branch. Large PRs are difficult to review. Be sure to break large PRs into smaller ones so that they can be reviewed quickly and deployed to production.

• Never commit passwords, access tokens, or other credentials into version control. If you think you absolutely have to, ask first. If you do this by accident, tell your manager immediately.
• Each commit should be as small and as simple as possible.
• The project must be operational and have all tests passing after every commit.
• Use Conventional Commits
  • Valid types are chore:, docs:, style:, refactor:, perf:, and test:
• Do not mix feature changes (added functionality) with fixes (restored functionality), refactors (no change in functionality), or style changes (only whitespace or other cosmetic changes).
• Before a PR is ready for review, make sure that it is a single commit. If the combined commit is too large or disparate, consider multiple PRs.
• The exception to the above single commit rule is when a PR introduces new packages. Create one extra commit in the same PR for each new package your PR needs.
• Do not modify a project's .gitignore to add files related to your editor or environment. Use your own global .gitignore for that instead.
• Be sure that your PRs have descriptive titles that explain what has been changed. Typically the commit message is sufficient. "Fixes #66" is not.
• When submitting a PR with UI or visual changes, please add before and after screenshots to the PR. This makes it easy for the reviewer to quickly see what has been done.