Contributing to Meridian¶
Thank you for your interest in contributing to Meridian. This guide covers the process for all repositories in the Meridian platform.
Getting Started¶
- Fork the repository
- Clone your fork and create a branch:
git checkout -b my-feature - Start the dev environment:
./launch_dev.sh - Make your changes
- Run tests (see per-repo instructions below)
- Commit with a DCO sign-off:
git commit -s -m "Add feature X" - Push and open a pull request
Developer Certificate of Origin (DCO)¶
All contributions to Apache 2.0 licensed repositories (meridian-core, design/, meridian-cli) require a DCO sign-off. This certifies that you wrote the code or have the right to submit it.
Add -s to your commit command:
This adds a Signed-off-by: Your Name <your@email.com> line to the commit.
Pull Request Process¶
- One concern per PR — don't bundle unrelated changes
- Describe what and why — the PR description should explain the change and its motivation
- Include tests — new features need tests, bug fixes need regression tests
- Pass CI — all tests must pass before review
- Keep it small — smaller PRs get reviewed faster
Code Style¶
Go (meridian-core, meridian-go, meridian-cli)¶
- Run
gofmtandgo vetbefore committing - Follow Effective Go
- Exported functions need doc comments
Python (meridian-python)¶
- Follow PEP 8
- Type hints on public API functions
- Docstrings on public classes and methods
Java, C++, Rust (coming soon)¶
These SDKs are in development and not yet public. Style guides will be published when they are released.
Running Tests¶
| Repository | Command |
|---|---|
| meridian-core | cd meridian-core && make test |
| meridian-python | cd meridian-python && python -m pytest tests/ |
| meridian-go | cd meridian-go && go test ./... |
| meridian-java | cd meridian-java && ./gradlew test |
| meridian-cpp | cd meridian-cpp && cmake --build build && ctest --test-dir build |
| meridian-rust | cd meridian-rust && cargo test |
| meridian-cli | cd meridian-cli && go test ./... |
Error Messages¶
Every error message should tell the developer what to do next. If you add or modify an error path, include an actionable suggestion:
# Bad
"ACL denied"
# Good
"ACL denied: plugin type 'signal' cannot publish to 'platform.oms.order.*'.
Signal plugins publish to 'platform.signal.*'. See docs."
Reporting Bugs¶
Open a GitHub Issue with: - What you expected to happen - What actually happened - Steps to reproduce - SDK version and language - OS and platform
Suggesting Features¶
Open a GitHub Discussion (not an Issue) for feature ideas. Include: - The problem you're trying to solve - Your proposed solution - Alternatives you've considered
Questions¶
- GitHub Discussions — for architecture and design questions
- Discord — for quick questions and community chat
- GitHub Issues — for bugs only
Not sure where to start?
- Browse
good first issuelabels on GitHub - Ask in Discord #contributors
- Read the SDK Core Concepts to understand the codebase