Process Guide

[jokosanyang]

Overview:
This issue is intended to document for our current processes within this project. Once everyone agrees on the document, contents should only be changed once discussed with and agreed by the whole team.

Linting:
We use eslint with the airbnb settings to ensure consistent, good-quality code.

Branches:
We work off a staging branch. This branch is only merged to master once we've got a complete product, ready to be deployed on Heroku.
Each new branch should start with one of the following:

• feature/
• fix/

depending on its function. It should also have hyphens (-) to separate words.

Commit messages:
Written in present tense (imperative) to describe what a commit does, rather than what it did.
E.g. Change color of search bar instead of Changed/changes color of search bar

Naming things:
Functions - camelCase, describe what it does
Classes - Block Element Modifier (BEM), useful video for recapping BEM rules
Tests - [filename].test.js
Routes - if more than one word, dash between words

Asynchronicity:
Whenever possible, use promises over callbacks.

Opening pull requests:
Follow the checklist below.
Create the PR and assign the other pair (who haven't worked on the code) as reviewers.
Relate the issue number either in the commit message or pull request message.

Merging pull requests:
Check through the code carefully, comment on anything questionable by hovering over the line and clicking the blue plus that appears.

• If changes need to be made, add the changes-needed label.
• If everything is a-okay, merge the pull request and delete the branch.

Accessibility:
Avoid divs in favour of semantic elements (eg section, header, button) wherever possible.
All form elements should have labels.
Follow guidelines from Oli's talk.
Use Aria roles as a last resort.

---

Before submitting a pull request:

• git pull staging and merge with branch locally to prevent conflicts
• relate relevant issue
• check the project runs
  • no bugs/errors in existing/new features
  • the branch can successfully be deployed to Heroku
• linter is used and generating no error messages
  • code is consistent with agreed team style
• files are named consistently and clearly
• tests are working
  • each new file written has a test file (where possible)
  • all tests should pass locally and on Travis
  • consider edge cases in tests
  • project test coverage stays over 95%
  • files and lines of code have been ignored if they cannot be tested
• no console logs except for crucial system messages (e.g. which port server is on).
  • console.error is used in error handling.