Process Guide

[someyaaltous]

Team: @bayan-404 @bayanseder @aboodswiti @Duha96
Project Lead: @someyaaltous

Issues and Labels

Should be used labels when creating issues.

Time

Time estimation, although hard, its very important. We ask that you try and include a time estimating with Dwyl Labels for every issue, even if you are not sure.
There are 5 built-in time labels:

• T1d: 1 day
• T1h: 1 hour
• T2h: 2 hours
• T4h: 4 hours (half-day)
• T25m: 25min
  When possible, when completing issues please leave a comment with the time actually taken to complete the issue.

[someyaaltous]

Linting

• Using eslint with the Airbnb style guide configuration

React Installing

To install the package and its dependencies:

$ npm install --save-dev eslint@4.19.1 \
                         eslint-config-pagarme-react \
                         stylelint@8.0.0 \
                         stylelint-config-pagarme-react \

The peer dependencies specified above have hardcoded versions.
If you prefer, you can use the command
npm info eslint-config-pagarme-react@latest peerDependencies
to find the exact peer dependencies to install.

To include these rules into your project, create the following config files in your root folder:

.eslintrc

{
  "extends": ["pagarme-react"],
  "env": {
    "browser": true
  }
}

.stylelintrc

{
  "extends": ["stylelint-config-pagarme-react"]
}

[someyaaltous]

Component definition

All components should always be defined as a directory, named with pascal casing. The main component file should be index.js, main stylesheet style.css like :

HomePage/
├── index.js
└── style.js using Material-UI 

[someyaaltous]

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 the color of search bar instead of Changed/changes color of search bar

[someyaaltous]

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 an agreed team style
• • Naming of files is consistent with the project (e.g. all files named with camelCase)
• All tests should pass locally and on Travis
• 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 one who opens the pull request is responsible for the final merge, but only after team lead and one of one teammate has reviewed, approved, and left a comment on the pull request to that effect