Skip to main content
The Bitcoin Core project operates an open contributor model where anyone is welcome to contribute towards development in the form of peer review, testing, and patches.

​
Understanding the Structure

There is no particular concept of “Bitcoin Core developers” in the sense of privileged people. Open source often naturally revolves around a meritocracy where contributors earn trust from the developer community over time. Nevertheless, some hierarchy is necessary for practical purposes, with repository maintainers responsible for merging pull requests, the release cycle, and moderation.

​
First Steps for New Contributors

1

Start with reviewing and testing

Reviewing and testing is highly valued and the most effective way you can contribute as a new contributor. It will teach you much more about the code and process than opening pull requests.
2

Familiarize yourself with the build system

Before you start contributing, familiarize yourself with the Bitcoin Core build system and tests. Refer to the documentation in the repository on:
  • How to build Bitcoin Core
  • How to run the unit tests
  • How to run the functional tests
  • How to run the fuzz tests
3

Find an issue to work on

There are many open issues of varying difficulty waiting to be fixed. Check out:
4

Leave a comment before starting work

You do not need to request permission to start working on an issue. However, you are encouraged to leave a comment if you are planning to work on it. This helps other contributors monitor which issues are actively being addressed and is an effective way to request assistance if and when you need it.
Participate in the Bitcoin Core PR Review Club to learn from experienced contributors while reviewing pull requests together.

​
Good First Issue Label

The purpose of the good first issue label is to highlight which issues are suitable for a new contributor without a deep understanding of the codebase. However, good first issues can be solved by anyone. If they remain unsolved for a longer time, a frequent contributor might address them.

​
Communication Channels

​
IRC

Most communication about Bitcoin Core development happens on IRC, in the #bitcoin-core-dev channel on Libera Chat.

​
GitHub

Discussion about codebase improvements happens in GitHub issues and pull requests.

​
Mailing List

The developer mailing list should be used to discuss complicated or controversial consensus or P2P protocol changes before working on a patch set.

​
Contributor Workflow

The codebase is maintained using the “contributor workflow” where everyone without exception contributes patch proposals using “pull requests” (PRs). This facilitates social contribution, easy testing and peer review.
1

Fork repository

Fork the repository (only needed the first time)
2

Create topic branch

Create a new branch for your changes:
git checkout -b my-feature-branch
3

Commit patches

Make your changes and commit them following the commit guidelines:
  • Commits should be atomic
  • Each commit should build successfully
  • Write verbose commit messages
4

Push changes to your fork

git push origin my-feature-branch
5

Create pull request

Open a pull request against the appropriate repository:

​
Repository Selection

As a rule of thumb, everything that only modifies src/qt is a GUI-only pull request. However:
  • For global refactoring or other transversal changes, use the node repository
  • For GUI-related build system changes, use the node repository because the change needs review by the build systems reviewers
  • Changes in src/interfaces need to go to the node repository because they might affect other components like the wallet
For large GUI changes that include build system and interface changes, it is recommended to first open a pull request against the GUI repository. When there is agreement to proceed with the changes, a pull request with the build system and interfaces changes can be submitted to the node repository.

​
What to Expect

Pull request authors must fully and confidently understand their own changes and must have tested them. Contributors should mention which tests cover their changes, or include the manual steps they used to confirm the change. Contributors are expected to be prepared to clearly motivate and explain their changes. If there is doubt, the pull request may be closed.