Welcome to the Reedelk developers community! If you are looking for help, thinking about getting involved in the project or trying to report a bug, you are in the right place!
You can get help from our Slack Developers Community. It is a great place for asking questions, giving advice and staying up-to-date with the latest announcements. The Slack Developers Community is frequented by other Reedelk Developers and by Reedelk maintainers.
Please avoid opening GitHub issues for general questions or help, as those should be reserved for actual bug reports. The Reedelk community is welcoming and more than willing to assist you on Slack channels!
Feel free to submit an issue on the GitHub repository, we would be grateful to hear about it! Please make sure to respect the GitHub issue template, and include:
- A summary of the issue
- A list of steps to reproduce the issue
- The version of Reedelk you encountered the issue with
- The Reedelk configuration, or the parts that are relevant to your issue
- A screenshot of the integration flow you are having the issue with (or its JSON definition)
If you wish, you are more than welcome to propose a patch to fix the issue! See the Submit a patch section for more information on how to best do so.
You can submit an issue for feature requests. Please add as much detail as you can.
You are also welcome to propose patches adding new features. See the section on Submitting a patch for details.
We welcome contributions of all kinds, you do not need to code to be helpful! All of the following tasks are noble and worthy contributions that you can make without coding:
- Reporting a bug (see the report bugs section)
- Helping other members of the community on the support channels
- Fixing a typo in the code
- Proposing new integration components proposing-new-components
- Providing your feedback on the proposed features and designs
- Reviewing Pull Requests
If you wish to contribute code (features or bug fixes), see the Submitting a patch section.
If you have a new integration component to suggest being part of the Reedelk components library you can submit an issue for feature requests. Please add as much detail as you can.
Feel free to contribute fixes or minor features, we love to receive Pull Requests! If you are planning to develop a larger feature, come talk to us first!
When contributing, please follow the guidelines provided in this document. They will cover topics such as the different Git branches we use or the commit message format to use.
Once you have read them, and you are ready to submit your Pull Request, be sure to verify a few things:
- Your work was based on the appropriate branch (
mastervs.development), and you are opening your Pull Request against the appropriate one - Your commit history is clean: changes are atomic and the git message format was respected
- Rebase your work on top of the base branch (seek help online on how to use
git rebase; this is important to ensure your commit history is clean and linear) - The tests are passing: run
mvn test - Do not update
releases.jsonyourself. Your change will be included there in due time if it is accepted.
If the above guidelines are respected, your Pull Request has all its chances to be considered and will be reviewed by a maintainer.
If your Pull Request was accepted and fixes a bug, adds functionality, or makes it significantly easier to use or understand Reedelk, congratulations! You are now an official contributor to Reedelk.
Your change will be included in the subsequent release, and we will not forget to include your name if you are an external contributor. 😉
We work on two branches: master, where non-breaking changes land, and development,
where important features or breaking changes land in-between major releases.
When contributing to Reedelk, this distinction is important. Please ensure that you are basing your work on top of the appropriate branch, it might save you some time down the road!
If you have write access to the GitHub repository, please follow the following naming scheme when pushing your branch(es):
feature/foo-barfor new featuresbugfix/foo-barfor bug fixestests/foo-barwhen the change concerns only the test suiterefactor/foo-barwhen refactoring code without any behavior change
To maintain a healthy Git history, we ask of you that you write your commit messages as follows:
- The tense of your message must be present
- The message must be prefixed by a type and a scope
The format for a commit message is as follows:
[type][scope][message]
Where type is one of:
feature: code belonging to a new featurebugfix: code belonging to a bugfixtests: code belonging to testsrefactor: code belonging to a refactoring or code improvementsmisc: changes to assets, strings, pom.xml and configuration files and so on.
Scope is one of:
module-descriptor: if the change refers to the module-descriptor projectmodule-maven-plugin: if the change refers to the module-maven-plugin projectmodule-parent: if the change refers to the module-parent projectruntime-admin-console: if the change refers to the runtime-admin-console projectruntime-api: if the change refers to the runtime-api projectruntime-commons: if the change refers to the runtime-commons projectruntime-launcher: if the change refers to the runtime-launcher projectruntime-platform: if the change refers to the runtime-platform project
Examples:
bugfix: runtime-platform: fixed serialization of JSON primitives.
feature: module-descriptor: added @Mandatory annotation to mark not empty properties.