Process Guide

[Dalmano]

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.

Contents:

• Standups
• Linting
• Naming Branches
• Commit messages
• Pull Request Checklist
• Merging Pull Requests
• Accessibility
• Stand-ups

Standups

Held at 10:30am London time

Please review the project board daily and check that it is up to date. At the end of the day, please add a note in the daily log on the kanban commenting on the issues you worked on, what issues you plan to take on and any blockers you may have.

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.

Naming Branches

• 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

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
  • Merging Pull Requests
  • The person that made the pull request is responsible for the final merge, but only after someone else from the team has reviewed, approved, and left a comment on the pull request to that affect

Accessibility

Code should be made accessible after writing. No pull requests without doing the bare minimum on accessibility.

[teenie-quaggard]

@Dalmano hey! Really good start to the set-up! As a reminder you can download the Dwyl Github labels from here (click on the heroku link) https://github.com/dwyl/labels

They should really help you get started on prioritizing your user stories. It seems like you have a lot to work on over the next few weeks, so having a think about what can be labelled as a stretch goal might be good!

[teenie-quaggard]

ps. on accessibility, I would recommend a chrome dev tool called Axe that you can run in your browser. https://www.deque.com/axe/

[Dalmano]

Thanks Kristina! finally managed to download the labels, going to use them tonight to prioritise issues. Yes a good few are stretch goals so will create another column for them as well as labels :)