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](https://github.com/Ontotext-AD/ontotext-platform-custom-scalars/issues).
* If you're unable to find an open issue addressing the problem, [open a new one](https://github.com/Ontotext-AD/ontotext-platform-custom-scalars/issues/new/choose)
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](https://github.com/Ontotext-AD/ontotext-platform-custom-scalars/issues/new/choose) 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](https://guides.github.com/)
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.