Thanks for your interest in contributing to RisingWave! We welcome and appreciate contributions.
This document describes how to submit your code changes. To learn about the development process, see the developer guide. To understand the design and implementation of RisingWave, refer to the design docs listed in docs/README.md.
If you have questions, you can search for existing discussions or start a new discussion in the Discussions forum of RisingWave, or ask in the RisingWave Community channel on Slack. Please use the invitation link to join the channel.
To report bugs, create a GitHub issue.
Before submitting your code changes, ensure you fully test them and perform necessary checks. The testing instructions and necessary checks are detailed in the developer guide.
As described in here, a valid PR title should begin with one of the following prefixes:
feat
: A new featurefix
: A bug fixdoc
: Documentation only changesstyle
: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)refactor
: A code change that neither fixes a bug nor adds a featureperf
: A code change that improves performancetest
: Adding missing tests or correcting existing testsbuild
: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)ci
: Changes to RisingWave CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)chore
: Other changes that don't modify src or test filesrevert
: Reverts a previous commit
For example, a PR title could be:
refactor: modify executor protobuf package path
feat(execution): enable comparison between nullable data arrays
, where(execution)
means that this PR mainly focuses on the execution component.
You may also check out previous PRs in the PR list.
- If your PR is small (such as a typo fix), you can go brief.
- If it is large and you have changed a lot, it's better to write more details.
Contributors will need to sign Singularity Data's CLA.