Team Process Guide

[kin-au]

Process Guide

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.

Agile methodology and scrum

• Standups will be held each day at 10.30am GMT.
• The scrum master is not a manager or project leader, however they are responsible for:
  • upholding agile values and principles
  • ensuring the team is following the agreed processes and practises
  • facilitating spring planning, sprint retrospective, sprint review and daily scrums
  • clearing obstacles impeding progress

Linting/Prettier

• Set up ESLint on one machine locally and add to project repo
• Any edits to the configuration files should initially be discussed and agreed upon

Branches

• Branch names should be prefixed with either fix__, feature__ or test__ depending on its function
• See this link on branch naming
• Keep branch names short and descriptive
• Hypens (-) should be used to separate words

Naming conventions

• CSS Classes - Block Element Modifier (BEM)
• Tests - [filename].test.js
• Express routes - if more than one word, hyphen (-) between words, lower case
• PostgreSQL - underscore (_) between words
• React - components go into separate folders, file names must be capitalised before being commited
• Functions and everything else - camelCase

Constants folder

• A single index.js file inside a src/constants folder should contain all global constants
• See example with routes and example with widths
• Use constants with import * as Constants from 'src/constants'

Asynchronicity

• Use promises and async/await instead of callbacks where possible

Accessibility

• Use <React.Fragment>, or just <></> instead of divs
• Ensure use of semantic HTML tags and aria-labels where necessary

Commit messages

• Should include reference to any co-authors
• Written in present tense (imperative) to describe what a commit does, rather than what it did

Pull Request Checklist

• You can download and install locally, and run the project locally
• All existing and new features run without bugs
• Linter/prettier is used, no error messages
• Code and naming conventions are followed
• Each new file written has a test file (where possible)
• All tests should pass locally and on Travis
• Any conflicts should be resolved by consulting the team member who did the work
• Edge cases have been considered in tests
• Console.log is only used for crucial system messages (e.g. which port server is on)
• Any console.logs used for debugging have been removed
• Console.error is used in error handling

Mergin Pull Requests

• Pull requests must be reviewed and approved by another member of the team
• Once approved the pull request should be merged by the reviewer
• Branches should be deleted after merging