Contributing changes

To understand what is non-breaking change and what is not, take a look at guidance related to breaking changes before proceeding, Breaking changes.

• If you find a bug, make an issue report first to the correct repository. Each version has own respository, for example the development version is always in https://github.com/Open-Data-Product-Initiative/open-data-product-spec-dev Likewise if you wish to add something to the standard, make a feature request first, do not just create pull request.

• In the bug report or feature request clearly state what the issue or what is the addition you wish to contribute. State the business value of addition and also your idea how to make the fix or feature you wish to contribute. Make sure you respond to all questions and take into account alternative ideas as well.

• After this you can start your contribution in practice. Use feature branching! Do not make pull requests directly to main/master. Develop your fix or feature addition locally and do thorough testing and documenting needed.

• Create a pull request (PR) to the appropriate repository. In the PR clearly link it with the issue you created in step 1. This way everyone can follow the breadcrumb to beginning and see what is this all about.

• All PRs must be reviewed by at least one maintainer. This might take a while, but be patient. This ensures higher quality of the specification. Reviewers might require you to do some changes before accepting the PR. You are responsible to make those changes, no one else. After changes push the PR again. Repeat this until at least 2 maintainers have accepted the pull request. If your contribution is not accepted and you do not provide update to the PR inside a month, PR will be neglected and related issue closed. This is to avoid issue backlog or PR count to grow too long and remain open.

• After the merge, maintainers will close the related issue with acceptance comments.