You have made your way to the contributing guidelines for DefraDB! You are about to be part of a wave making databases decentralized and more powerful.
This document is to help you with the process of contributing to the project. First recommendation is to become familiar with the project documentation. Familiarity with Git, Go, and Github is assumed.
All contributions are appreciated, whether it's identifying problems, highlighting missing features, or contributing to the codebase in straightforward or complex ways.
You're invited to join the Source Network Discord, where you can discuss ideas, ask questions, and find inspiration for what to build next.
Obtain the repository, then build and run it.
git clone https://github.com/sourcenetwork/defradb.git
cd defradb
make start
Refer to the README.md
and project documentation for usage examples.
Methodologies the project follows:
- Issue-driven development: Every pull request links to issue(s).
- Squash and merge: Commits of a pull request are squashed into one before being merged onto the
develop
branch. - Conventional commits: Every commit message is of the
<type>: <description>
format in which "type" is one offeat
,fix
,tools
,docs
,perf
,refactor
,test
,ci
,chore
.
Basic development flow:
- Make changes.
- Usually, write tests of the changed behavior.
- Ensure that
make test
andmake lint
are passing.
Creating an issue:
- On github.com/sourcenetwork/defradb/issues, click "New issue".
- Select the relevant issue type.
- Fill the issue template.
Submitting a contribution:
- Fork the repository and with your changes create a branch following the convention
<your-name>/<type>/<description>
, for exampleoctavio/feat/compression-lru-data
. - Create a pull request targeting the
develop
branch. Link the relevant existing issue(s), and create one if no related issue exists yet. Follow the instructions of the pull request template. Use a verb in the PR title to describe the code changes. - Read through and accept the Contributor License Agreement, if it's your first contribution.
- Request review from the database-team. Discuss and adapt the pull request accordingly.
- If approved, click "Squash and merge" to squash it into one commit and to merge in
develop
. Make sure the title of the commit follows the Conventional Commits convention.
make test
to run the unit tests and integration tests.
make lint
to run the linters.
make bench
to run the benchmark suite. To assess the difference between a branch's results and the develop
branch's results, execute the suite on both outputting the results to files, and compare the two with e.g. benchstat develop.txt current.txt
. To install benchstat
use make deps:bench
.
make test:changes
to run a test suite detecting breaking changes. Breaking changes need to be accompanied by documentation in docs/data_format_changes/
for the test to pass.
The overall project's documentation is found at docs.source.network, and its source at github.com/sourcenetwork/docs.source.network.
The code documentation, doc comments, can be viewed as a website:
go install golang.org/x/pkgsite/cmd/pkgsite@latest
cd your-path-to/defradb/
pkgsite
# open http://localhost:8080/github.com/sourcenetwork/defradb
- go.dev/doc/comment has guidelines on writing Go doc comments.
docs/cmd/
is where auto-generated documentation of the defradb
command-line program is.
docs/data_format_changes/
details the historical breaking changes to data persistence.
This section includes good-to-know information for advanced contributors.
Dependency management:
go mod tidy
should be performed by pull requests changing dependency requirements.- The project uses
dependabot
for automatic creation of pull requests updating dependencies.
Peer review of pull requests:
- Using the Conventional Comments methodology is recommended.
Licensing:
- The BSL license header must be included at the top of every code file.
Project management:
- Milestones and a project board are used to coordinate work on releases.