How to Contribute to YugabyteDB and Related Projects

October 9, 2025

This blog provides an overview of how you can get started contributing to YugabyteDB and related ecosystem projects (such as the Debezium connector). It covers contribution guidelines, coding standards, legal requirements, community resources, a quick-start workflow, common pitfalls, and a visual guide to the process.

1. Contribution Overview

Contributing to YugabyteDB or its ecosystem follows an open-source model. The process is transparent, collaborative, and designed to help contributors succeed.

The documents above outline:

How to set up your development environment
How to submit pull requests (PRs)
The review and merge process
Ways to contribute beyond code (e.g., documentation, testing, feedback)

2. Coding Style

All contributions must follow the official coding style guidelines to ensure consistency across the codebase.

The YugabyteDB coding style guide

The guide includes:

Formatting standards
Naming conventions
Testing expectations
Best practices for writing clear and maintainable code

This applies to YugabyteDB and ecosystem projects (e.g., connectors, integrations, and tools).

3. The Contributor License Agreement (CLA)

Before submitting your first pull request, you must sign the Individual Contributor License Agreement (CLA).

You can sign here: CLA Assistant – YugabyteDB

The CLA ensures:

You confirm the code is your original work
You retain ownership of your contributions
Yugabyte is granted the right to use and distribute the code

You only need to sign once, and this signature will apply to all future contributions.

4. Community Engagement

YugabyteDB has an active and welcoming open source community. Contributors are encouraged to join, share, and collaborate.

Join the YugabyteDB open source community

The YugabyteDB community provides:

Direct access to YugabyteDB engineers and contributors
Channels for technical discussions, Q&A, and project updates
Opportunities to connect with peers working on similar contributions

5. First Contribution Workflow (Quick Start)

Follow these steps to make your first contribution to YugabyteDB or a related ecosystem project:

Fork the repository
- Go to the project’s GitHub page (e.g., yugabyte/yugabyte-db)
- Click Fork to create your own copy under your GitHub account

Clone your fork

git clone https://github.com/<your-username>/yugabyte-db.git
cd yugabyte-db

Create a new branch
```
git checkout -b fix-typo-docs
```
Use a descriptive branch name (e.g., fix-typo-docs, add-test-case, improve-logging).
Make your changes
- Follow the coding style guide
- Add or update tests if needed
- Verify everything builds and tests pass
Commit your changes
```
git add .
git commit -m "#GHI Fix typo in replication docs"
```
Where GHI is the GitHub Issue number, for example, “#12345 Fix typo in replication docs”
Push your branch
```
git push origin fix-typo-docs
```
Open a Pull Request (PR)
- On GitHub, go to your fork and click compare and pull request
- Fill in the PR template, describing your changes clearly
- Submit the PR to the upstream yugabyte-db repository
Participate in code review
- Respond to reviewer comments
- Make any requested changes
- Once approved, your contribution will be merged

6. Common Pitfalls and Tips

Many first-time contributors run into the same challenges. Keep these common pitfalls in mind to avoid delays:

Git and Branch Management

Forgetting to rebase: Always rebase your branch against the latest master before opening or updating a PR

git fetch upstream

git rebase upstream/master

Use rebase, not merge: Use rebase to keep the history clean. Avoid git merge upstream/master unless specifically requested

Contributor License Agreement (CLA)

CLA not signed: If your PR shows a “CLA check failed,” sign the Contributor License Agreement and re-run the check

Common Code Style and Testing Issues

Not following coding style: Ensure you run formatters and linters before pushing changes. Check the coding style guide
Missing tests: Your contributions should include relevant unit or integration tests where possible
Lint Errors: yugabyte-db build system treats lint errors as fatal build errors; they will break the build

Continuous Integration (CI) Failures

Ignoring CI results: PRs won’t be merged if CI checks fail. Check the logs in GitHub Actions for details
Flaky tests: If a test fails intermittently, mention it in your PR comments. Maintainers may advise on next steps

Pull Request Etiquette

Oversized PRs: Keep PRs focused and small. Large PRs take longer to review and may be harder to merge
Unclear commit messages: Use descriptive commit messages (e.g., “Fix memory leak in DocDB compaction”) rather than generic ones (“Fix stuff”). All relevant data should be in the commit message itself; avoid links as explanations
Not filling in the PR template: Reviewers rely on the PR description for context. Always complete it thoroughly

Community and Communication

Working in isolation: If you’re tackling a significant feature or change, discuss it in Community Slack before you start. This avoids duplicate work and ensures alignment
Not asking for help: If you’re stuck, maintainers and community members are available to guide you

7. Next Steps for New Contributors

Review the Contribution Overview and Core Database Guide
Familiarise yourself with the coding style guide
Sign the Contributor License Agreement
Join the YugabyteDB Community Slack
Start with a small issue or documentation fix to become familiar with the contribution workflow. There are some great first GitHub issues to start on here
```
 (filter by state:open label:"good first issue").
```