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