Process guide

[Ayub3]

Overview:

This guide is intended to document all our process for this project.

Stand-ups:

Will take place every morning at 10:30 am London time.Three simple questions will be covered during the meeting to highlight progress and help flag team blockers.

• What did you work on yesterday?
• What am you working on today
• What issues are blocking me?

Set-up:

To ensure consistency and good-quality code, we shall set-up Eslint to analyse our for potential errors in order to ensure consistent and good-quality code.

Branches:

Everyone should work on their own branch and your branch can only be merged to the master branch after a code review.

Branch names should start with the following:

• feature/
• fix/

E.g. feature/add-search-function.

Depending on the function name, it should have a hyphen (-) to separate the words and all the words should be lower case.

Commit messages:

All commit messages should be written in the present tense to describe what a commit does rather than what it did.

E.g.
‘Change colour of the nav bar’.

Naming conventions:

Naming variable and Functions

• Use camelCase
• Describe what it does
• Use pascal case for component (eg. Drop)

React Components:

• File and component folders should always be capitalised before being
  pushed to staging / master branches
• ‘Every’ component should have its own style file and test file.

E.g:

Components (Folder)
	> Header (Folder)
		>Header.js
		>Header.css
		>Header.test.js

This is a how a typical component folder should look like.

Asynchronicity

• Use promises whenever possible.

Accessibility

Use semantic HTML, avoid using too many divs. Instead get into the habit of using.
All form elements should have labels.
Use this a guideline

Prior to submitting a pull request

• git pull and merge master in order to avoid any conflicts.
• Relate any relevant issue in your commit message
• Check if the project runs locally
• Files names are consistent and clear.
• Tests are passing
• no console logs except for crucial system messages (e.g. which port server is on).

Before final handover:

• Delete old branches if we have not done so.
• Delete unnecessary commented out code
• Tidy up all codebase
• Delete console.logs
• Keep it accessible