github.com/celestiaorg/celestia-node@v0.15.0-beta.1/CONTRIBUTING.md (about)

     1  # Contributing
     2  
     3  Thank you for your interest in contributing to Celestia-Node!
     4  
     5  All work on the code base should be motivated by [our Github
     6  issues](https://github.com/celestiaorg/celestia-node/issues). If you
     7  would like to work on an issue which already exists, please indicate so
     8  by leaving a comment.
     9  
    10  All new contributions should start with a [Github
    11  issue](https://github.com/celestiaorg/celestia-node/issues/new/choose). The
    12  issue helps capture the problem you're trying to solve and allows for
    13  early feedback. Once the issue is created the process can proceed in different
    14  directions depending on how well-defined the problem and potential
    15  solution are. If the change is simple and well understood, maintainers
    16  will indicate their support with a heartfelt emoji.
    17  
    18  When the problem is well understood but the solution leads to large structural
    19  changes to the code base, these changes should be proposed in the form of an
    20  [Architectural Decision Record (ADR)](./docs/adr/). The ADR will help
    21  build consensus on an overall strategy to ensure the code base maintains
    22  coherence in the larger context. If you are not comfortable with writing an
    23  ADR, you can open a less-formal issue and the maintainers will help you turn it
    24  into an ADR.
    25  
    26  > How to pick a number for the ADR?
    27  
    28  Find the largest existing ADR number and bump it by 1.
    29  
    30  Each stage of the process is aimed at creating feedback cycles which align contributors and maintainers to make sure:
    31  
    32  - Contributors don’t waste their time implementing/proposing features which won’t land in master.
    33  - Maintainers have the necessary context in order to support and review contributions.
    34  
    35  ## PR Naming
    36  
    37  PRs should be titled as following:
    38  
    39  ```txt
    40  pkg: Concise title of PR
    41  ```
    42  
    43  **Example:**
    44  
    45  ```txt
    46  service/header: Remove race in core_listener
    47  ```
    48  
    49  ## Branching Model and Release
    50  
    51  The main development branch is `main`.
    52  
    53  Every release is maintained in a release branch named `vX.Y`. On each respective release branch, we tag the releases
    54  vX.Y.0, vX.Y.1 and so forth.
    55  
    56  Note all pull requests should be squash merged except for merging to a release branch (named `vX.Y`). This keeps the commit history clean and makes it
    57  easy to reference the pull request where a change was introduced.
    58  
    59  ### Development Procedure
    60  
    61  The latest state of development is on `main`, which must never fail `make test`. *Never* force push `main`.
    62  
    63  To begin contributing, create a development branch on your fork.
    64  
    65  Make changes, and before submitting a pull request, update the `CHANGELOG_PENDING.md` to record your change. Also, `git
    66  rebase` on top of the latest `main`.
    67  
    68  Sometimes (often!) pull requests get out-of-date with main, as other people merge different pull requests to main. It is
    69  our convention that pull request authors are responsible for updating their branches with `main`. (This also means that you shouldn't update someone else's branch for them; even if it seems like you're doing them a favor, you may be interfering with their git flow in some way!)
    70  
    71  #### Merging Pull Requests
    72  
    73  It is also our convention that authors merge their own pull requests, when possible. External contributors may not have the necessary permissions to do this, in which case, a member of the core team will merge the pull request once it's been approved.
    74  
    75  Before merging a pull request:
    76  
    77  - Ensure pull branch is up-to-date with a recent `main` (GitHub won't let you merge without this!)
    78  - Run `make test` to ensure that all tests pass
    79  - Ensure that all other CI checks pass / are green
    80  - [Squash](https://stackoverflow.com/questions/5189560/squash-my-last-x-commits-together-using-git) merge pull request
    81  
    82  ### Git Commit Style
    83  
    84  We follow the [Go style guide on commit messages](https://tip.golang.org/doc/contribute.html#commit_messages). Write concise commits that start with the package name and have a description that finishes the sentence "This change modifies Celestia-Node to...". For example,
    85  
    86  ```sh
    87  cmd/debug: execute p.Signal only when p is not nil
    88  
    89  [potentially longer description in the body]
    90  
    91  Fixes #nnnn
    92  ```
    93  
    94  It is recommended to prepend the type of change the commit is making to the commit message as documented [here](https://www.conventionalcommits.org/en/v1.0.0/).
    95  
    96  ```txt
    97  feat(service/header): Title of PR.
    98  ```
    99  
   100  Each PR should have one commit once it lands on `main`; this can be accomplished by using the "squash and merge" button on Github. Be sure to edit your commit message, though!
   101  
   102  ## Testing
   103  
   104  ### Unit tests
   105  
   106  Unit tests are located in `_test.go` files as directed by [the Go testing
   107  package](https://golang.org/pkg/testing/). If you're adding or removing a
   108  function, please check there's a `TestType_Method` test for it.
   109  
   110  Run: `make test`
   111  
   112  ## Protobuf
   113  
   114  If your PR modifies `*.proto` files, you will need to regenerate protobuf files with `make pb-gen`. Note this command assumes you have installed [protoc](https://grpc.io/docs/protoc-installation/).