Blog

How to Contribute to Dolt: A Community Contributor's Take

D
REFERENCE
8 min read

I’ve contributed a handful of times to Dolt and Doltgres over the past few months. Some were small bug fixes. Others were 1000+ line feature additions. If you’ve ever wanted to contribute to a product-ready open source project, but didn’t know where to start, this is for you.

Background#

I’m a software engineer with a background in big data, distributed systems, and Go. I stumbled across Dolt when I was looking for an open source database-related project written in Go. I wanted to contribute and give back to the open source community that’s given me so much. I’m a big believer that contributing to mature, large, open source projects, like Dolt and Doltgres, makes you a better engineer.

What drew me to Dolt specifically? The codebase is well-organized, the community is active on Discord, and the “Git for Data” concept is genuinely novel. Within a few weeks of discovering Dolt, I had my first PR merged. A few months later, I’ve contributed more than a handful of changes; those contributions range from 2-line parser fixes to a ~1,000-line feature addition.

This post is the guide I wish I’d had when I started.

Why Contribute to Dolt?#

Active, Welcoming Community#

The Dolt team is incredibly responsive on Discord. Questions get answered quickly. PRs get reviewed within days, not weeks. The code review feedback is thorough, but constructive. This isn’t a project where your contribution will sit in limbo.

Learn Database Internals#

Working on Dolt gives you hands-on experience with database internals. You’ll see how a storage engine works, how SQL gets parsed and executed, and how Git-style version control translates to database operations. It’s a production database written in Go, which makes it accessible if you know the language.

Real Impact#

Contributions you make get used by real people. Companies like Turbine, Flock Safety, and Scorewarrior run Dolt in production. Your bug fix or feature addition directly helps them. That’s a great feeling.

Variety of Contribution Types#

You don’t have to build a massive feature to contribute:

  • Bug fixes - Found an issue? Fix it.
  • Error message improvements - Better UX counts.
  • Documentation - Always needed.
  • Test improvements - Help prevent regressions.
  • Doltgres contributions - The Postgres flavor is newer with more low-hanging fruit.

No CLA Required#

Dolt uses the Apache 2.0 license and ditched the CLA back in 2021. This means you can contribute without signing away any rights. Fork the repo, make your changes, submit a PR. That’s it.

Getting Started#

Fork and Clone#

Use the standard GitHub workflow. Fork via GitHub UI, then:

git clone https://github.com/YOUR_USERNAME/dolt.git
cd dolt

Development Environment Setup#

Both Dolt and Doltgres have detailed setup instructions:

These guides cover prerequisites, platform-specific setup (including macOS and Windows gotchas), and how to build from source. It’s important to read them before jumping into the code.

Finding Features/Issues to Work On#

The best place to start is the GitHub issues page for Dolt or Doltgres.

Look for these labels to find good starting points:

  1. good first issue - Explicitly marked as beginner-friendly. These are great for your first contribution.
  2. help wanted - The team is actively looking for contributors on these issues.
  3. bug - Something’s broken and needs fixing. If there are no issues labeled as “good first issue”, bugs are often straightforward to tackle.
  4. bad error message - Improve the developer experience.
  5. enhancement - Feature additions and improvements. These often require deeper knowledge of the codebase, so if you’re new, look for smaller, well-scoped enhancements rather than diving into a major feature.

Doltgres Is Full of Opportunities#

Doltgres is the Postgres-flavored version of Dolt. Unlike Dolt, which reached 1.0 stability in May 2023, Doltgres is still in active development and is currently in Beta. Often, this means more low-hanging fruit for contributors and rapid iteration on new features.

That said, contributing to an unstable project comes with more unknowns given APIs may change, features might get reworked, and you may encounter rough edges. If you’re comfortable with that tradeoff and want to make an early impact, Doltgres is a great place to start. If you prefer a more predictable codebase, stick with Dolt.

Learn from Existing PRs#

Don’t just look at open issues; check out closed and merged PRs too. They’re valuable learning resources that show you what good contributions look like, common pitfalls to avoid, and how the review process works. Pay attention to the code review discussions to understand what the team looks for in contributions.

When in Doubt, Ask#

Have an idea for a feature, but don’t see an issue for it? Jump on Discord and ask if the feature would be welcome. The team is very responsive about discussing potential contributions.

The Pull Request Process#

Before You Submit#

Write tests first. Seriously. Most, if not all, contributions should always include both unit tests and BATS integration tests. It’s unlikely your contribution’s PR will be approved and merged without them.

At minimum, run the specific tests related to your changes:

  1. Unit tests for a specific package
go test ./path/to/package
  1. BATS integration tests

Dolt uses BATS (Bash Automated Testing System) for end-to-end CLI tests, catching issues unit tests might miss. Tests live in integration-tests/bats/:

bats <relevant-test-file>.bats

Here’s what a BATS test looks like:

@test "dolt diff with filter flag shows only added rows" {
    dolt sql -q "INSERT INTO t VALUES (1, 'new')"
    run dolt diff --filter=added
    [ "$status" -eq 0 ]
    [[ "$output" =~ "new" ]]
}

Look at existing tests for patterns. They’re readable and straightforward. For more info check out this blog from Tim Sehn covering BATS testing.

If you want to be thorough, run the full Go test suite with go test ./…, but for a quick sanity check before pushing, focus on what you changed. CI tests will help reveal if your changes had unexpected side-effects on other parts of the code you didn’t directly touch.

Self-review your changes. Read your own diff before submitting. You’ll catch obvious mistakes. You can also have an AI agent review your diff. Ask it to look for bugs, edge cases, or anything that might raise questions during code review.

PR Structure That Works#

Here’s what a good Dolt PR looks like:

  1. Clear title: Clearly state the description of your change and reference the issue number
  2. Summary section: TL;DR of what changed and why
  3. Implementation details: Key changes and design decisions
  4. Testing section: What tests were added and what edge cases they cover
  5. Usage examples: Show how to use the new feature

Code Review Process#

Reviews are thorough, but constructive. Expect at least 1-3 rounds of feedback. The team will point out issues, suggest improvements, and ask clarifying questions. Once CI passes and reviewers approve, a maintainer merges your PR.

The DoltHub team is very fast at reviewing PRs; most of my PRs were reviewed within a day or two. If you haven’t heard anything for ~3 days, don’t hesitate to post in the #dolt or #doltgresql Discord channel accordingly as the team is responsive and happy to help.

Debugging CI Failures#

When your PR fails CI, don’t panic, it happens to everyone. The GitHub Actions logs can be overwhelming, so here’s how to quickly find what broke. For Go test failures, search the failed job’s logs for FAIL: to jump straight to the failing test and its error output. For BATS test failures, search for not ok since BATS prefixes failed tests with this, making them easy to spot. Don’t scroll through the logs manually. Instead, use your browser’s find function (Cmd+F or Ctrl+F) with these patterns.

A note on flaky tests: Some CI tests are flaky, and others occasionally fail for outside contributors due to environment or permissions differences. If your code-related tests pass locally, but CI is failing on unrelated tests, don’t bang your head against the wall. Ask for help on Discord. The team can tell you if it’s a known issue or re-run the CI for you.

Using AI Coding Agents#

Let’s talk about the elephant in the room: AI coding assistants.

Why Use Coding Agents?#

Dolt and Doltgres are large codebases. I’ve used Claude Code extensively to help me understand the codebase and reason through the changes I need to make. The Dolt team explicitly invited contributors to use coding agents on Dolt and Doltgres. AI agents are invaluable for codebase exploration (“Where is the import logic handled?”), understanding context (“How does dolt diff work?”), reasoning through changes, verifying fixes against specific issues, and reviewing your diff for bugs or edge cases before submitting. Other options include Cursor and GitHub Copilot.

The Critical Rule: Never Commit Code You Don’t Understand#

Never commit code or open a PR with changes you can’t fully explain.

This isn’t just about quality, it’s about respect for reviewers and the project. When you submit a PR, you’re implicitly saying “I understand this change and can defend it.” Reviewers will ask questions. They’ll want to know why you chose a particular approach. If your answer is “the AI wrote it,” you’ve wasted their time and damaged your credibility.

AI-generated code can have subtle bugs, miss edge cases, or make incorrect assumptions about the codebase. You are responsible for every line in your PR. The coding agent can help you write it, but you need to understand it deeply enough to explain the change to a reviewer, debug it when something goes wrong, and know what tests are needed to verify correctness.

Read every line. Test manually. Use the agent as a learning tool to accelerate your understanding, not as a replacement for it. AI agents are accelerators, not autopilots.

Tips for Success#

Engage with the community: Join Discord first to ask questions, get context, and see what others are working on. Check stale PRs too as they often have valuable discussion.

Understand before changing: Start with tests to understand expected behavior before modifying code. Read the DoltHub blog for architecture deep-dives. It’s an underrated engineering blog with excellent technical content.

Optimize for review: Small PRs get reviewed faster, so split large changes if possible. Reference issue numbers in your PR description and commit messages. Write organized, atomic commits with descriptive messages; consider using conventional commits.

Don’t be intimidated: It’s well-organized Go code. You can figure it out.

Beyond Code: Other Ways to Contribute#

Not ready to write code? You can still help by trying out Dolt or Doltgres. More users means more bugs discovered and more feature ideas. Report bugs with detailed issues, answer questions on Discord, write about your use case in blog posts or tutorials, suggest features with detailed proposals, or improve documentation. All of these contributions matter.

Conclusion#

Contributing to Dolt has been my favorite open source experience. The team is welcoming, the reviews are constructive, and you get to work on a genuinely interesting problem. The feedback I’ve received from DoltHub engineers during code review has been very helpful.

If you’ve ever used open source software, I encourage you to give back by contributing to a project. I hope that project is Dolt or Doltgres. You don’t need to be a database expert to contribute. You just need curiosity, willingness to learn, and the ability to write (or fix) some code.

I’ll see you on Discord. Happy coding.

Blog