Process Guide

[teenie-quaggard]

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.

Values

Project prioritizes a11y: a11y project

• [ ] Written in semantic HTML
• [ ] Avoids divs (uses React Fragments or appropriate semantic tag)
• [ ] Forms are appropriately labelled
• [ ] Site is accessible by keyboard navigation (appropriate interactive elements are focussable)
• [ ] Uses WCAG AAA Color contrast in our styling
• [ ] Uses aria labels when text is not visible on the screen
• [ ] Uses aria-labelledby attribute where necessary

TDD

• [ ] Javascript functions will be written as pure functions so they are testable
• [ ] Javascript should be written in TDD

Pre-project checklist

• [x] Personal introductions via email
• [x] Create Gitter room
• [x] Create repo with project documentation and process guide
• [x] Fill out user manuals
• [x] Hold a meeting outlining the project aims and going over workshop documentation
• [x] Decide on project roles

Stand-ups

Standups will be held at 13:00 London time, 15:00 Palestine time.

In order to keep focus, our aim for standups will be 15min every day. They will focus on what you are currently working on, what you plan to do next and if you have any blockers. Discussions at stand up should revolve around things that concern the whole team.

Additional time for discussion can be arranged immediately following standup for questions or getting help from one another. This can be done in pairs or larger groups.

Please review the kanban daily and check that it is up to date.

At the end of every day, please add a note in the daily log on the kanban commenting on the issues that you worked on, what issues you plan to take on and any blockers you may have.

This will be especially important as there will be times when we will be working across 4 cities in different timezones and we want to make sure that it is clear what every one is doing.

Workflow / PRs

• Issues will be created by Scrum master and added to the kanban
• Team members can pick up any issue in the priority column by assigning themselves it and by dragging it into the in progress column of the kanban
• When the ticket has been completed, the team member should check that it passes the Pre-PR Checklist:

---

Pre Pull Request Checklist

• Branch is up to date with master
• The project runs
• • [ ] You can download and install locally, and run the project locally
• • [ ] All existing and new features run without bugs
• • [ ] The build script runs without error
• • [ ] (If the project is already deployed to Heroku) the branch to be merged can deploy successfully to Heroku
• Code is consistent
• • [ ] Linter is used, no error messages
• • [ ] Code is consistent with agreed team style
• • [ ] Naming of files is consistent with project (e.g. all files named with camelCase)
• Tests are in place
• • [ ] Test file is in the same folder as the original file, with the extension .test.js
• • [ ] Each new file written has a test file (where possible)
• [ ] Tests all pass
• • [ ] All tests should pass locally and on Travis
• • [ ] Edge cases have been considered in tests
• Test coverage is maintained
• • [ ] Project coverage stays > 95%
• • [ ] PR will not bring down coverage by more than 1%
• • [ ] Files and lines of code have been ignored if they cannot be tested
• No console logs
• • [ ] 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.
• • [ ] global.console.log and global.console.error are mocked in tests when needed to avoid littering the console

---

• Once this checklist is passed, the team member will open up a PR. This PR will NOT be added to the kanban, it should only live in the pull request tab of Github. The PR should reference the issue number(s) that it relates to.
• The PR should be labelled with awaiting review when it is ready to be reviewed. The corresponding issues can then be moved in the review column on the kanban.
• The reviewing team members can use the approved label if they are happy for the PR to be merged. Alternatively they can ask for changes and add the changes requested tag.
• It is up the discretion of the reviewer, but if the PR is getting quite big, it can often be better approve the current branch and to open up a new issue citing the necessary changes and linking the issues using the issue number. This keeps the depth of changes on the working branch quite shallow so that all members of the team are working on code that is quite similar.
• merge conflicts tag should be used if the PR needs to be merged with working branch
• After the team member has completed the changes, they can label the PR with awaiting review and wait for an approved review.
• PRs made by London team should wait for at least one approved review from the Palestinian team, PRs made by Palestinian team, must wait for at least one approved review from the London team
• The PR should always be merged by the person who opened it.
• After the PR has been merged, the branch should be deleted and the corresponding issues on the kanban should be closed.

Naming Branches

• Branch naming follows feature/fix convention
  • E.g. feature/add-search-function or fix/change-searchbar-color

Commit Messages

• Should include issue #
• Written with 'imperative tone' 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

Staging and Master branches

• We will use two main branches in our workflow
• The staging branch will be our main working branch - this is where we will branch off of as a team and make our PRs into.
• The staging branch will only be merged into the master branch when we see that staging has been deployed successfully and is bug-free
• This is a convention that allows us to test new code on our staging branch to see that it passes all tests without breaking our public-facing site.
• This convention is more important in projects with a bigger / longer scope, but is good practice to set early on.

Linting

• To begin with, we would suggest using eslint with the airbnb style guide configuration for easy setup (to be done on one computer and added to project file)
• Further edits to the linter configuration file can be discussed, agreed on, and documented here.

Installing modules

• The installing of modules should be discussed as a team
• Whoever installs module should include it on the project readme, linking it the documentation and including a few sentences on what it does in the project

React-js extension

• stick with convention of using js instead of jsx.
  • E.g. button.js instead of button.jsx

React Component File Structure

• To keep things as unnested as possible, we prefer to organize our component folder without folders:

Ex:

|-components/
  |-About.js
  |-About.style.js
  |-About.test.js
  |-AboutArticle.js
  |-AboutArticle.style.js
  |-AboutArticle.test.js
  |-Add.js
  |-Add.style.js
  |-Add.test.js
  |-CommonHeader.js
  |-CommonHeader.style.js
  |-CommonHeader.test.js
  |-CommonFooter.test.js
  |-CommonFooter.style.js
  |-CommonFooter.test.js

In child components that are rendered in a parent, start the component name with the parent component so that when listed alphabetically, they will stay together. In the example above, Article would be a component rendered in About. Common components can start with Common.

Styled Components

• Project should use a global theme to hold global css variables such as font styles/sizes, colors and margins (should be made at the beginning of the project)
• we should be as consistent as possible with our styled components naming convention. An approach that I suggest is to import * from the styling sheet - as is in this example.

import Header from ‘Components/Header’;
import * as S from ‘./styles';
const Navigation = () => (
  <S.Navigation>
    <Header>{headerContent}</Header>
    <S.Content>{content}</S.Content>
  </S.Navigation>
);

• We can write the style file like this:

  
  import styled from 'styled-components';

export const Label = styled.label //STYLES HERE// ;

export const Input = styled.input //STYLES HERE// ;

For more: https://medium.com/inturn-eng/naming-styled-components-d7097950a245

## Constants Folder
- constants folder should hold all routes for an easy update at a later date 
![Screen Shot 2019-04-28 at 16 17 24](https://user-images.githubusercontent.com/37771591/56866451-2fa5ff00-69d1-11e9-9db8-d8faa4708429.png)
- can also hold widths for consistent break points
![Screen Shot 2019-04-28 at 16 18 29](https://user-images.githubusercontent.com/37771591/56866458-49474680-69d1-11e9-9c50-a5b9a04b795d.png)

[SalwaMugh]

@teenie-quaggard can you please add what the responsibilities from each project role ?

[Oliversw]

Project Role Summaries

Scrum Master

• responsible for backlog and prioritization of issues
• main point of contact with the Product Owner
• runs standup each day

UI/UX

• champion for good ui/ux including accessible design
• responsible for ensuring that everyone follows the figma
• in charge of global styles and css architecture

DevOps

• initial setup of repo and file system
• manages and maintains deployment to Heroku and Travis

QA

• champion for testing
• makes sure that everyone is writing tests and provides support where possible

[Oliversw]

@teenie-quaggard can you add anything that I might have missed please? 🙂

[teenie-quaggard]

@teenie-quaggard can you add anything that I might have missed please? 🙂

looks good to me. just edited the comment to include accessiblity to ux/ui

[Oliversw]

@SalwaMugh there is some info about roles in the comments above!