Hazelcast is Open Source software, licensed under the Apache 2.0 license. The main benefit of Open Source is that you don't need to wait for a vendor to provide a fix or a feature. If you've got the skills (and the will), it's already at your fingertips.
There are multiple ways to contribute:
- Reporting an issue
- Sending a pull request. Note that you don't need to be a developer to help us. Contributions that improve the documentation are always appreciated.
If you feel yourself in need of assistance, please reach us directly via Slack.
Thanks for reporting your issue. To help us resolve your issue quickly and efficiently, we need as much data for diagnostics as possible. Please share with us the following information:
- Exact Hazelcast version that you use (e.g.
4.0.1
, also whether it is a minor release, or the latest snapshot). - Cluster size, i.e. the number of Hazelcast cluster members.
- Number of clients.
- Java version. It is also helpful to mention the JVM parameters.
- Operating system. If it is Linux, kernel version is helpful.
- Logs and stack traces, if available.
- Detailed description of the steps to reproduce your issue.
- Unit test with the
hazelcast.xml
file. If you could include a unit test which reproduces your issue, it would speed the resolution time. - If it's related to integration with an external system (e.g. Tomcat, Spring, Hibernate, Kafka) details about the external system and configuration parameters for connecting to it.
Thanks a lot for creating your PR!
A PR can target many different subjects:
- Documentation: either fix typos or improve the documentation as a whole
- Fix a bug
- Add a feature
- Add additional tests to improve the test coverage, or fix flaky tests
- Anything else that makes Hazelcast better!
All PRs follow the same process:
- Contributions are submitted, reviewed, and accepted using the PR system on GitHub.
- For first time contributors, our bot will automatically ask you to sign the Hazelcast Contributor Agreement on the PR.
- The latest changes are in the
master
branch. - Make sure to design clean commits that are easily readable. That includes descriptive commit messages.
- Please keep your PRs as small as possible, i.e. if you plan to perform a huge change, do not submit a single and large PR for it. For an enhancement or larger feature, you can create a GitHub issue first to discuss.
- Before you push, run the command
mvn clean validate
in your terminal and fix the CheckStyle errors if any. Push your PR once it is free of CheckStyle errors. - If you submit a PR as the solution to a specific issue, please mention the issue number either in the PR description or commit message.