51 lines
1.7 KiB
Markdown
51 lines
1.7 KiB
Markdown
|
# How to Contribute to Litmus
|
||
|
|
|
||
|
|
We'd love your help!
|
||
|
|
|
||
|
|
We gratefully welcome improvements to documentation as well as to code.
|
||
|
|
|
||
|
|
Table of Contents:
|
||
|
|
|
||
|
|
* [How to set up locally](#how-to-set-up-locally)
|
||
|
|
* [Making a Change](#making-a-change)
|
||
|
|
* [Branches](#branches)
|
||
|
|
|
||
|
|
## How to set up locally
|
||
|
|
* Install Java 17
|
||
|
|
* Install Postgres, Redis with bloom filter module, Kafka
|
||
|
|
|
||
|
|
## Making a Change
|
||
|
|
|
||
|
|
**Before making any significant changes, please open an issue**. Each issue
|
||
|
|
should describe the following:
|
||
|
|
|
||
|
|
* Requirement - what kind of business use case are you trying to solve?
|
||
|
|
* Problem - what in Litmus blocks you from solving the requirement?
|
||
|
|
* Proposal - what do you suggest to solve the problem or improve the existing
|
||
|
|
situation?
|
||
|
|
* Any open questions to address
|
||
|
|
|
||
|
|
Discussing your proposed changes ahead of time will make the contribution
|
||
|
|
process smooth for everyone. Once the approach is agreed upon, make your changes
|
||
|
|
and open a pull request (PR). Each PR should describe:
|
||
|
|
|
||
|
|
* Which problem it is solving. Normally it should be simply a reference to the
|
||
|
|
corresponding issue, e.g. `Resolves #13`.
|
||
|
|
* What changes are made to achieve that.
|
||
|
|
|
||
|
|
Your pull request is most likely to be accepted if **each commit**:
|
||
|
|
|
||
|
|
* Has a [good commit message][good-commit-msg]. In summary:
|
||
|
|
* Separate subject from body with a blank line
|
||
|
|
* Limit the subject line to 50 characters
|
||
|
|
* Capitalize the subject line
|
||
|
|
* Do not end the subject line with a period
|
||
|
|
* Use the imperative mood in the subject line
|
||
|
|
* Wrap the body at 72 characters
|
||
|
|
* Use the body to explain _what_ and _why_ instead of _how_
|
||
|
|
|
||
|
|
## Branches
|
||
|
|
|
||
|
|
Upstream repository should contain only maintenance branches (e.g. `release-1.0`). For feature
|
||
|
|
branches use forked repository.
|