Github default configuration files. To add in a `.github` dir at the root of your project (used for Nomad Education)

CODE_OF_CONDUCT.md

Code of Conduct

Prerequisites

We are all adults. Capable of having adult discussions.

Our Standards

We should always be capable to criticize other people's work as long as the discussion is constructive.

Our Responsibilities

As engineers, we know that there's always some compromises to do (time to market, urgent vs. important). Therefore, make sure that the project is always maintaining the best level of quality possible.

CONTRIBUTING.md

Contributing

First, read our code of conduct. By participating, you are expected to uphold this code.

Workflow

Before coding

• Read the README file.
• Install the project on your machine.
• Launch tests (if there're any).
• Check your Trello board.
• Create or assign yourself to a specific card.
• Move it to the "In progress" column.

Conception/Testing

• If you need to make some research, don't hesitate to document every step.
• If you notice that one of the project dependency contains a bug, you're most welcome to fix it (we LOVE open-source!).
• While this may look surprising at first, you should create your tests before doing any code-related work (Note that this doesn't apply to legacy code).

Coding/Git atomic commit

• We encourage you to use the git command instead of GUI like SourceTree.
• An atomic commit is:
  • one irreducible "type" (see the complete list below)
  • generally small therefore faster to comprehend
  • ease the review for finding typos or bugs.
• Use our convention when making commit messages
• Try to describe the "why" vs the "what" in your commit messages.
• Use git add -p before git commit, it's always better to make a review of your changes by yourself before other can see your code.

Preparing your code review

• Don't forget to launch the test runner before creating the Pull Request
• Write your PR based on the template
• Request a review to at least 2 people
• You're encourage to rewrite your git commit history if you got redundant commits for example.

Code review process

• You need at least one "approved" review to get your code merged into the "master" branch
• If approved, it's the reviewer responsability to merge your PR.
• If some changes are requested, you'll code the fixes and then add it to your commit history using git fixup
  • After commiting your fixups, it's best to add the "status:need-rebase" label so reviewers will not accidently merged your PR
  • If your fixups are approved then it's your responsability to merge your PR since you need to rewrite the history (using git rebase --autosquash).
• If your PR is affecting the business code, you'll first need to test this code on the "staging" environment. To do that, you'll add the need-staging-validation label to your PR to prevent other reviewer from merging.
• If your PR is behaving as predicted on "staging", just remove the need-staging-validation label and add the staging-validated label so other reviewer know that they can safely merged it.

Styleguides

Git commit messages

• Use the angular commit style
• commit prefixes explanation:
  • chore: everything related to maintenance around the code (gulp, travis, fixtures, etc)
  • docs: related to documentation (README, code comments, etc)
  • feat: new functionality
  • fix: bugfix(es)
  • refactor: code improvement, removal of uneeded pieces
  • style: whitespace changes
  • test: code used for tests (unit & functional)

Code styleguide

• Use an editorconfig plugin for your IDE.
• Use an eslint plugin for your IDE.

Documentation styleguide

• Use github-flavoured markdown.
• Use direct phrases, omit needless words and follow this guide.

👍🎉 Happy coding! 🎉👍

ISSUE_TEMPLATE.md

Description

Explain what you did, what you expected to happen, and what actually happens.

Reproduction

Give as much details as possible to indicate how can we recreate this issue.

PULL_REQUEST_TEMPLATE.md

Purpose

Changes