Skip to content

Latest commit

 

History

History
92 lines (60 loc) · 4.83 KB

CONTRIBUTING.md

File metadata and controls

92 lines (60 loc) · 4.83 KB

Welcome

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.

Getting started

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.

Development flow

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 of feat, fix, tools, docs, perf, refactor, test, ci, chore.

Basic development flow:

  1. Make changes.
  2. Usually, write tests of the changed behavior.
  3. Ensure that make test and make lint are passing.

Creating an issue:

  1. On github.com/sourcenetwork/defradb/issues, click "New issue".
  2. Select the relevant issue type.
  3. Fill the issue template.

Submitting a contribution:

  1. Fork the repository and with your changes create a branch following the convention <your-name>/<type>/<description>, for example octavio/feat/compression-lru-data.
  2. 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.
  3. Read through and accept the Contributor License Agreement, if it's your first contribution.
  4. Request review from the database-team. Discuss and adapt the pull request accordingly.
  5. 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.

Testing

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.

Documentation

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

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.

Additional information

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:

Licensing:

Project management: