You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/CONTRIBUTING.md
+26-75Lines changed: 26 additions & 75 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,7 +2,7 @@
2
2
3
3
Thank you for your interest in our implementation of the Polkadot Runtime Environment Implementation! We're excited to get to know you and work with you on gossamer. We've put together these guidelines to help you figure out how you can help us.
4
4
5
-
At any point in this process feel free to reach out on [Discord](https://discord.gg/Xdc5xjE) with any questions or to say Hello :)
5
+
At any point in this process feel free to reach out on [Discord](https://discord.gg/M5XgXGRv) with any questions or to say Hello :)
6
6
7
7
## Getting Started
8
8
@@ -12,87 +12,45 @@ The Web3 Foundation has a [Polkadot Wiki](https://wiki.polkadot.network/docs/get
12
12
13
13
The [Polkadot Runtime Specification](https://research.web3.foundation/en/latest/_static/pdfview/viewer.html?file=../pdf/polkadot_re_spec.pdf) serves as our primary specification, however it is currently in its draft status so things may be subject to change.
14
14
15
-
One important distinction is that we are building the Polkadot Runtime Environment, not Polkadot itself. Given that, although a deep understanding of Polkadot is helpful, it's not critical to contribute to gossamer. To help understand how the Runtime Environment relates to Polkadot, check out this [talk that one of our team members gave at DotCon](https://www.youtube.com/watch?v=nYkbYhM5Yfk).
15
+
To understand more about Parachain Protocol please refer to [The Polkadot Parachain Host Implementers Guide](https://paritytech.github.io/polkadot-sdk/book/index.html).
16
+
Additionally information about design that is done by our team for some modules refer to our [design docs](https://github.com/ChainSafe/gossamer/tree/development/docs/docs/design)
17
+
or [Gossamer blogposts](https://blog.chainsafe.io/gossamer/).
18
+
19
+
And there are many more articles and videos that we are willing to share if you are interested. So please come by to our [Discord](https://discord.gg/M5XgXGRv) channel to ask for help or simply say hi.
16
20
17
21
For coding style, you may refer to the [code style](CODE_STYLE.md) document which we keep up to date with coding style conventions we have for this repository.
18
22
19
23
## Contribution Steps
20
-
21
-
1.**Fork the gossamer repo.**
22
-
2.**Create a local clone of gossamer.**
23
-
24
-
```sh
25
-
go get -u github.com/ChainSafe/gossamer
26
-
cd$GOPATH/src/github.com/ChainSafe/gossamer
27
-
git init
28
-
```
29
-
30
-
You may encounter a `package github.com/ChainSafe/gossamer: no Go files in ...` message when doing `go get`. This is not an error, since there are no go files in the project root.
31
-
32
-
3. **Link your local clone to the fork on your Github repo.**
git remote -v (you should see myrepo and gossamer in the list of remotes)
43
-
```
44
-
45
-
5. You can optionally setup Git hooks defined in this repository with `make githooks`.
46
-
6. **Find something to work on.**
47
-
48
-
To start, check out our open issues. We recommend starting with an [issue labeled `Good First Issue`](https://github.com/ChainSafe/gossamer/issues?q=is%3Aopen+is%3Aissue+label%3A%22Good+First+Issue%22). Leave a comment to let us know that you would like to work on it.
49
-
50
-
Another option is to improve gossamer where you see fit based on your evaluation of our code. In order to best facilitate collaboration, please create an issue before you start working on it.
51
-
52
-
7. **Make improvements to the code.**
53
-
54
-
Each time you work on the code be sure that you are working on the branch that you have created as opposed to your local copy of the gossamer repo. Keeping your changes segregated in this branch will make it easier to merge your changes into the repo later.
55
-
56
-
```sh
57
-
git checkout -b feature-in-progress-branch
58
-
```
59
-
60
-
8. **Test your changes.**
61
-
62
-
Changes that only affect a single file can be tested with
24
+
1. Make sure you're familiar with our contribution guidelines (this document)!
25
+
2. Find an issue you want to work on. We have a ["good first issue" label on github](https://github.com/ChainSafe/gossamer/issues?q=is%3Aissue%20state%3Aopen%20label%3A"good%20first%20issue). To avoid duplicate efforts or working on outdated tasks, please clarify your intentions in the issue comments before starting. This step ensures there are no parallel executions of the same issue and confirms its validity for implementation.
26
+
3. Create your own fork of this repository.
27
+
4. Make your changes in your local fork.
28
+
5. If you've made a code change, make sure to lint and test your changes.
29
+
Changes that only affect a single file can be tested with
63
30
64
31
```sh
65
32
go test<file_you_are_working_on>
66
33
```
67
34
68
-
Sometimes you may need to create mocks forinterfaces,in that case, add a go generate comment. For example, forinterface `Client`in the `dot/telemetry` package, the comment would be:
35
+
Sometimes you may need to create mocks forinterfaces,in that case, add a go generate comment. For example, forinterface `Client`in the `dot/telemetry` package, the comment would be:
This will generate a Go file `mock_myinterface_test.go` with the `Client` mock. Note this is only accessible
75
-
in your current package since it's written to a `_test.go` file. We prefer to generate mocks locally where they are needed instead of sharing them to reduce package dependency and the Go API 'noise'.
41
+
This will generate a Go file `mock_myinterface_test.go` with the `Client` mock. Note this is only accessible
42
+
in your current package since it's written to a `_test.go` file. We prefer to generate mocks locally where they are needed instead of sharing them to reduce package dependency and the Go API 'noise'.
76
43
77
-
Generate the mock code with `go generate -run "mockgen" ./...` from your working directory. This will also update existing mocks. You can update all mocks by running `go generate -run "mockgen" ./...` from the repository root. Note this does not log anything out.
78
-
79
-
> To execute `//go:generate` commands that are placed at files with `//go:build integration` remember to add `-tags integration` in the `go generate` command eg. `go generate -tags integration ...`
80
-
81
-
9. **Lint your changes.**
82
-
83
-
Before opening a pull request be sure to run the linter
44
+
Before opening a pull request be sure to run the linter
84
45
85
46
```sh
86
47
make lint
87
48
```
88
-
89
-
10. **Add licenses to new Go and Proto files**
90
-
49
+
6. **Add licenses to new Go and Proto files**
91
50
If you added any new file, run `make license` to setup all licenses on relevant files.
92
51
If you do not have `make` available, you can copy paste the command from the Makefile's `license:` block and run that instead.
93
-
11. **Create a pull request.**
94
-
95
-
Navigate your browser to [https://github.com/ChainSafe/gossamer](https://github.com/ChainSafe/gossamer) and click on the new pull request button. In the “base” box on the left, change the branch to “**base development**”, the branch that you want your changes to be applied to. In the “compare” box on the right, selectfeature-in-progress-branch, the branch containing the changes you want to apply. You will then be asked to answer a few questions about your pull request. After you complete the questionnaire, the pull request will appear in the list of pull requests at [https://github.com/ChainSafe/gossamer/pulls](https://github.com/ChainSafe/gossamer/pulls).
52
+
7. Make an open pull request when you're ready for it to be reviewed. We review PRs on a regular basis. See Pull request etiquette for more information.
53
+
8. You may be asked to sign a Contributor License Agreement (CLA). We make it relatively painless with CLA-bot.
96
54
97
55
## Note on memory intensive tests
98
56
@@ -175,7 +133,7 @@ If a change does not alter any logic (e.g. comments, dependencies, docs), then i
175
133
### Labels
176
134
177
135
The set of labels and their description can be found [labels.yml](/.github/labels.yml).
178
-
To change update this file and CI will automatically add/remove changed labels.
136
+
To change update this file and CI will automatically add/remove changed labels.
179
137
180
138
### Process
181
139
@@ -204,21 +162,14 @@ Anyone can become a part-time contributor and help out on gossamer. Contribution
204
162
- Engaging in Discord conversations, asking questions on how to contribute to the project
205
163
- Opening up Github issues to contribute ideas on how the code can be improved
206
164
- Opening up PRs referencing any open issue in the repo. PRs should include:
207
-
- Detailed context of what would be required for merge
208
-
- Tests that are consistent with how other tests are written in our implementation
165
+
- Detailed context of what would be required for merge
166
+
- Tests that are consistent with how other tests are written in our implementation
209
167
- Proper labels, milestones, and projects (see other closed PRs for reference)
210
168
- Follow up on open PRs
211
-
- Have an estimated timeframe to completion and let the core contributors know if a PR will take longer than expected
212
-
213
-
We do not expect all part-time contributors to be experts on all the latest Polkadot documentation, but all contributors should at least be familiarized with the fundamentals of the [Polkadot Runtime Specification](https://research.web3.foundation/en/latest/polkadot/specifications/runtime.html).
169
+
- Have an estimated timeframe to completion and let the core contributors know if a PR will take longer than expected
214
170
215
171
### Core Contributors
172
+
Core contributors are currently comprised of members of the ChainSafe Systems team.
216
173
217
-
Core contributors are currently comprised of members of the ChainSafe Systems team. Core devs have all of the responsibilities of part-time contributors plus the majority of the following:
218
-
219
-
- Participate in our software development process (standups, sprint planning, retrospectives, etc)
220
-
- Stay up to date on the latest Polkadot research and updates
221
-
- Commit high quality code on core functionality
222
-
- Monitor github issues and PR’s to make sure owner, labels, descriptions are correct
223
-
- Formulate independent ideas, suggest new work to do, point out improvements to existing approaches
224
-
- Participate in code review, ensure code quality is excellent and test coverage is high
174
+
### Join Core team
175
+
If you have an intention of joining the core team, please
0 commit comments