Skip to content

How to contribute

Jump to bottom
Luis Iñesta edited this page May 19, 2022 · 4 revisions

Please read this guide before contributing to this project.

Contribution flow

  1. Create a new issue describing the bug or feature you want to implement, or choose one existing issue.
  2. Fork the project here
  3. Create a new branch from the branch main. Include the number of issue in the branch name.
  4. Make the proper changes in the code
  5. Create a Pull Request to merge into main
  6. Check the result of the PR build. If the build fails for any reason (failing tests, code quality gate, etc.), make the proper changes and push again until the build phase finishes successfully.
  7. Project maintainers will review your contribution and they will accept or reject it.
  8. If your contribution is finally accepted and merged into the main branch, you will be acknowledged in the README file and the documentation site of the project (unless you ask not to).

PR requirements

In order to get your PR accepted, it must abide by the following:

  • Bound to a issue : each PR needs to solve one, and only one, open issue. PRs without a clear and delimited intention would be not accepted. If there is no current issue stating the situation you want to solve, please create one prior to make code changes.

  • Well documented : update the CHANGELOG file of the affected modules with a brief annotation to keep track of your change, including the issue number (check this site to know how changelog files are structured in this project). You should add your change description to the [Unreleased] section. If further comments are needed to explain your change, you can include them in the discussion section of the PR.

  • Only pertinent modifications : restrict your changes to the issue subject, do not include additional modifications that are not related. It is preferable to open several PR than a single one stuffed with non-related modifications.

  • Tests : you have to implement automatic tests that prove the correctness of your changes. When solving a bug, make sure there is a failing test reflecting the issue, and create a new test if it does not exist yet.

  • Code Quality Gate : this project uses SonarCloud to ensure code quality. The PR changes would be automatically checked and rejected if the quality gate is not achieved. You can access to the Sonar analysis and check what you should fix prior to merging the code.

Your well-meaning contribution may be not accepted by the maintainers of the project for other factors not listed here. If that is the case, feel free to ask the reasons and engage in a friendly discussion. And, more than anything... be polite. Any kind of of rude or inappropriate interaction would end up in automatic rejection of the current and future contributions.

Exception: Non-functional contributions

You can contribute to any documentation file fixing typos, adding translations, or clarifying points that are not well-enough explained. In those cases, the only requirement is to state clearly the intention in the PR.

Clone this wiki locally