Skip to content

Latest commit

 

History

History
37 lines (28 loc) · 2.46 KB

CONTRIBUTING.md

File metadata and controls

37 lines (28 loc) · 2.46 KB

First of all, thanks for taking the time to read this section and contributing to the project!

When contributing to this repository, please first discuss the change you wish to make via issue, email, or any other method with the owners of this repository before making a change.

Please note we have a code of conduct, please follow it in all your interactions with the project.

Did you find a bug?

  • Ensure the bug was not already reported by searching on GitHub under Issues.
  • If you're unable to find an open issue addressing the problem, open a new one by following the provided template. Be sure to include a title and clear description, as much relevant information as possible, and a code sample or an executable test case demonstrating the expected behavior that is not occurring.

Do you intend to add a new feature or change an existing one?

  • If you plan to change the public API of the library, or make a major refactoring, our recommendation is to create an issue first by using the Feature request template. This will allow us to reach an agreement on the proposal before you put significant effort in it.

Pull Request Process

  1. Ensure you are familiar with the best practices and Github workflows - Guides
  2. Ensure any install or build dependencies are removed before the end of the layer when doing a build.
  3. Update the README.md with details of changes to the interface, this includes new environment variables, exposed ports, useful file locations and container parameters.
  4. Update the CHANGELOG.md with simple details of the changes or reference to the related issue.
  5. You may merge the Pull Request in once you have the sign-off of at least one other developer, or if you do not have permission to do that, you may request the reviewer to merge it for you.

Coding Rules

The rules we follow promotes clean, well documented and tested code which helps development process to be smooth and makes the library very developer friendly.

  • We enforce code style by running the linting step as a part of repository CI/CD process.
  • All features and bug fixes are covered with unit and/or component level tests.
  • All public API methods are properly documented including JSDoc tags.