> ## Documentation Index
> Fetch the complete documentation index at: https://mintlify.com/bitcoin/bitcoin/llms.txt
> Use this file to discover all available pages before exploring further.

# Getting Started with Contributing

> Learn how to start contributing to Bitcoin Core through peer review, testing, and patches

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

<Steps>
  <Step title="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.
  </Step>

  <Step title="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
  </Step>

  <Step title="Find an issue to work on">
    There are many open issues of varying difficulty waiting to be fixed. Check out:

    * [good first issue](https://github.com/bitcoin/bitcoin/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) list for beginner-friendly issues
    * [up for grabs](https://github.com/bitcoin/bitcoin/issues?utf8=%E2%9C%93\&q=label%3A%22Up+for+grabs%22) issues that need attention
  </Step>

  <Step title="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.
  </Step>
</Steps>

<Tip>
  Participate in the [Bitcoin Core PR Review Club](https://bitcoincore.reviews/) to learn from experienced contributors while reviewing pull requests together.
</Tip>

## 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.

* Access via web client: [web.libera.chat](https://web.libera.chat/#bitcoin-core-dev)
* Chat history logs:
  * [erisian.com.au](https://www.erisian.com.au/bitcoin-core-dev/)
  * [gnusha.org](https://gnusha.org/bitcoin-core-dev/)

### GitHub

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

### Mailing List

The developer [mailing list](https://groups.google.com/g/bitcoindev) should be used to discuss complicated or controversial consensus or P2P protocol changes before working on a patch set.

* Archives: [gnusha.org/pi/bitcoindev](https://gnusha.org/pi/bitcoindev/)

## 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.

<Steps>
  <Step title="Fork repository">
    [Fork the repository](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/fork-a-repo) (only needed the first time)
  </Step>

  <Step title="Create topic branch">
    Create a new branch for your changes:

    ```bash theme={null}
    git checkout -b my-feature-branch
    ```
  </Step>

  <Step title="Commit patches">
    Make your changes and commit them following the [commit guidelines](/contributing/code-review#committing-patches):

    * Commits should be atomic
    * Each commit should build successfully
    * Write verbose commit messages
  </Step>

  <Step title="Push changes to your fork">
    ```bash theme={null}
    git push origin my-feature-branch
    ```
  </Step>

  <Step title="Create pull request">
    Open a pull request against the appropriate repository:

    * **GUI-only changes**: [bitcoin-core/gui](https://github.com/bitcoin-core/gui)
    * **All other changes**: [bitcoin/bitcoin](https://github.com/bitcoin/bitcoin)
  </Step>
</Steps>

## 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

<Tip>
  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.
</Tip>

## 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.