Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
100 lines (75 loc) · 3.98 KB

CONTRIBUTING.md

File metadata and controls

100 lines (75 loc) · 3.98 KB

Contributing

We would love for you to contribute to this project and help make it even better than it is today! As a contributor, here are the guidelines we would like you to follow. It does help everyone to accept your Pull Requests with maximum awesomeness:

Code of Conduct

Please read and follow our [Code of Conduct][coc].

General Steps

  1. Check if there is already an open issue for the subject;
  2. Open an issue to discuss the new feature;
  3. Fork this repository;
  4. Create your feature branch: git checkout -b feat/my-new-feature;
  5. Add files changed: git add --all;
  6. Commit your changes: git commit -m "feat: Add some feature";
  7. Push to the branch: git push origin feat/my-new-feature;
  8. Submit a pull request;

Commits and Pull Requests

  • ❌ AVOID breaking the continuous integration build;
  • ✔️ DO atomic commits to make it easier to analyze changes;
  • ✔️ DO keep pull requests small so they can be easily reviewed;
  • ✔️ DO only commit with conventional commit patterns;

Conventional Commits

To know more about conventional commits, visit Conventional Commits.

In general the pattern mostly looks like this:

<type>(<scope>): <short summary>
  │       │             │
  │       │             └─⫸ Summary in present tense. Not capitalized. No period at the end.
  │       │
  │       └─⫸ Commit Scope: *
  │
  └─⫸ Commit Type: feat|fix|docs|style|refactor|perf|build|test|ci|chore|merge|revert

Real world examples can look like this:

chore: run tests on travis ci

fix(server): send cors headers

feat(blog): add comment section

Common types you can use (based on the Angular convention)

  • feat: A new feature;
  • fix: A bug fix;
  • docs: Documentation only changes;
  • style: Changes that do not affect the meaning of the code (white-space, formatting, missing semicolons, etc);
  • refactor: A code change that neither fixes a bug nor adds a feature;
  • perf: A code change that improves performance;
  • build: Changes that affect the build system or external dependencies (example scopes: nugets, npm, SDKs, etc);
  • test: Adding missing tests or correcting existing tests;
  • ci: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs);
  • chore: Other changes that don't modify src or test files;
  • merge: Merge a branch into another branch;
  • revert: Reverts a previous commit;

Coding Standards

  • ✔️ DO add XML comment documentation to new classes, methods or parameters;
  • ✔️ DO add a test class for each feature and a test method for each;
  • ✔️ DO use language conventions to make code easy to understand quickly;
  • ✔️ CONSIDER using SOLID patterns;

Tests

  • ✔️ DO add a unit test if your Pull Request resolves an issue or adds features;
  • ✔️ CONSIDER using test patterns like "AAA" and "Given When Then";
  • ✔️ DO add a test class for each feature and a test method for each assertion;
  • ✔️ DO make sure unit tests pass;
  • ❌ AVOID adding tests just to get coverage on SonarCloud;

Disclaimer

  • 1️⃣ Unit in Unit Test is not a method/function;
  • 2️⃣ One assertion per test doesn't mean invoking the Assert method only once;