Skip to content

Latest commit

 

History

History
68 lines (43 loc) · 2.92 KB

CONTRIBUTING.md

File metadata and controls

68 lines (43 loc) · 2.92 KB

Contributing with this open source

Have you some ideas of interesting enhancement ? Follow the steps please

  • Check if it isin't publicaded on the issues list
  • Post it on the issues list following the pattern

Did you find some bug ? Follow the steps please

  • Check if it isin't publicaded on the issues list
  • Post it on the issues list following the pattern

Would like to implement some enhancement or correction ? Follow the steps please

  • Create a pull request following the pattern

contact @Peedrooo for any quest = )

Contributing Policies

  1. Branch Names

Use descriptive names for branches (e.g., feature/new-login-page).

  1. Branch Creation Create a branch for every new feature or bugfix. Ensure an associated issue or user story exists before creating a branch.

  2. Commit patterns

Use Conventional Commits for commit specification.

The commit message should be structured as follows:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

The commit contains the following structural elements, to communicate intent to the consumers of your library:

  • fix: a commit of the type fix patches a bug in your codebase (this correlates with PATCH in Semantic Versioning).
  • feat: a commit of the type feat introduces a new feature to the codebase (this correlates with MINOR in Semantic Versioning).
  • BREAKING CHANGE: a commit that has a footer BREAKING CHANGE:, or appends a ! after the type/scope, introduces a breaking API change (correlating with MAJOR in Semantic Versioning). A BREAKING CHANGE can be part of commits of any type.
  • types other than fix: and feat: are allowed, for example @commitlint/config-conventional (based on the Angular convention) recommends build:, chore:, ci:, docs:, style:, refactor:, perf:, test:, and others.
  • footers other than BREAKING CHANGE: may be provided and follow a convention similar to git trailer format.

  1. Issue Tracking Connect each branch to a specific issue or user story.

  2. Pull Request (PR)

Follow the pattern while creating PR's

Follow the PR process:

  • Conduct a code review.
  • Test your changes.

  1. Code Quality Maintain coding standards. Include tests. Run code linters.

  2. Documentation Keep documentation up-to-date with code changes.