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:
Pushing your PR once it is free of CheckStyle errors.
./mvnw clean validate
- 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.
- Your PRs will first be merged into our internal repo.
- Following internal merging, the final commit will be pushed back to this repository.
- You will be acknowledged as a co-author of the final commit, recognizing your valuable contribution.
- Your original PR will be closed, accompanied by a comment indicating that it has been merged internally as part of the monorepo process.