General guidelines

If you want to contribute to openMINDS directly, feel free to fork the respective GitHub repositories and open pull requests with your changes. Note, that larger changes and new features should be first raised and discussed as an issue on the respective openMINDS before making a pull request. Minor bug fixes can, of course, still be made directly as a pull request without raising an issue first.

Please be aware that on any openMINDS version branch which has an official release tag in place, only backwards compatible changes are accepted. This can include corrections of typos in instructions, introduction of additional properties to schemas, loosening constraints on expected value numbers or formats, granting additional relations between schemas, and adding new schemas (if they do not require relational changes in existing schemas). Except for typo corrections, these changes (if accepted) are typically later tagged as sub-releases for the respective major version (e.g., v1.1) by the openMINDS development team. 

Non-backwards compatible changes are only accepted for version branches that do not have an official release tag yet, or lead to the creation of a new version branch (with a respectively increased major version number). This is true for renaming of existing properties, increasing constraints on expected value numbers or formats, removing relations between schemas and adding new schemas, if they cause relational changes in existing schemas.

For all contributions, make sure that you describe well what you plan to do / have done to speed up the evaluation / review process of your issue / pull request. The assigned member of the openMINDS development team will get back to you as soon as possible to discuss or give the blessing to your contribution.  Note that, all contributing community members are welcome to provide comments on active issues and pull requests.