|
1 |
| -= Contributing |
| 1 | +# Contributing |
2 | 2 |
|
3 | 3 | `Substrate` projects is a **OPENISH Open Source Project**
|
4 | 4 |
|
5 |
| -== What? |
| 5 | +## What? |
6 | 6 |
|
7 | 7 | Individuals making significant and valuable contributions are given commit-access to a project to contribute as they see fit. A project is more like an open wiki than a standard guarded open source project.
|
8 | 8 |
|
9 |
| -== Rules |
| 9 | +## Rules |
10 | 10 |
|
11 | 11 | There are a few basic ground-rules for contributors (including the maintainer(s) of the project):
|
12 | 12 |
|
13 |
| -. **No `--force` pushes** or modifying the Git history in any way. If you need to rebase, ensure you do it in your own repo. |
14 |
| -. **Non-master branches**, prefixed with a short name moniker (e.g. `gav-my-feature`) must be used for ongoing work. |
15 |
| -. **All modifications** must be made in a **pull-request** to solicit feedback from other contributors. |
16 |
| -. A pull-request *must not be merged until CI* has finished successfully. |
17 |
| -. Contributors should adhere to the https://github.com/paritytech/polkadot/wiki/Style-Guide[house coding style]. |
| 13 | +- **No `--force` pushes** or modifying the Git history in any way. If you need to rebase, ensure you do it in your own repo. |
| 14 | +- **Non-master branches**, prefixed with a short name moniker (e.g. `gav-my-feature`) must be used for ongoing work. |
| 15 | +- **All modifications** must be made in a **pull-request** to solicit feedback from other contributors. |
| 16 | +- A pull-request _must not be merged until CI_ has finished successfully. |
| 17 | +- Contributors should adhere to the https://github.com/paritytech/polkadot/wiki/Style-Guide[house coding style]. |
18 | 18 |
|
19 |
| -Merging pull requests once CI is successful: |
| 19 | +#### Merging pull requests once CI is successful: |
20 | 20 |
|
21 |
| -. A pull request that does not alter any logic (e.g. comments, dependencies, docs) may be tagged https://github.com/paritytech/substrate/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+label%3AA2-insubstantial[`insubstantial`] and merged by its author. |
22 |
| -. A pull request with no large change to logic that is an urgent fix may be merged after a non-author contributor has reviewed it well. |
23 |
| -. All other PRs should sit for 48 hours with the https://github.com/paritytech/substrate/pulls?q=is%3Apr+is%3Aopen+label%3AA0-pleasereview[`pleasereview`] tag in order to garner feedback. |
24 |
| -. No PR should be merged until all reviews' comments are addressed. |
| 21 | +- A pull request that does not alter any logic (e.g. comments, dependencies, docs) may be tagged https://github.com/paritytech/substrate/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+label%3AA2-insubstantial[`insubstantial`] and merged by its author. |
| 22 | +- A pull request with no large change to logic that is an urgent fix may be merged after a non-author contributor has reviewed it well. |
| 23 | +- All other PRs should sit for 48 hours with the https://github.com/paritytech/substrate/pulls?q=is%3Apr+is%3Aopen+label%3AA0-pleasereview[`pleasereview`] tag in order to garner feedback. |
| 24 | +- No PR should be merged until all reviews' comments are addressed. |
| 25 | + |
| 26 | +#### Reviewing pull requests: |
25 | 27 |
|
26 |
| -.Reviewing pull requests: |
27 | 28 | When reviewing a pull request, the end-goal is to suggest useful changes to the author. Reviews should finish with approval unless there are issues that would result in:
|
28 | 29 |
|
29 |
| -. Buggy behaviour. |
30 |
| -. Undue maintenance burden. |
31 |
| -. Breaking with house coding style. |
32 |
| -. Pessimisation (i.e. reduction of speed as measured in the projects benchmarks). |
33 |
| -. Feature reduction (i.e. it removes some aspect of functionality that a significant minority of users rely on). |
34 |
| -. Uselessness (i.e. it does not strictly add a feature or fix a known issue). |
| 30 | +- Buggy behaviour. |
| 31 | +- Undue maintenance burden. |
| 32 | +- Breaking with house coding style. |
| 33 | +- Pessimisation (i.e. reduction of speed as measured in the projects benchmarks). |
| 34 | +- Feature reduction (i.e. it removes some aspect of functionality that a significant minority of users rely on). |
| 35 | +- Uselessness (i.e. it does not strictly add a feature or fix a known issue). |
| 36 | + |
| 37 | +#### Reviews may not be used as an effective veto for a PR because: |
35 | 38 |
|
36 |
| -.Reviews may not be used as an effective veto for a PR because: |
37 |
| -. There exists a somewhat cleaner/better/faster way of accomplishing the same feature/fix. |
38 |
| -. It does not fit well with some other contributors' longer-term vision for the project. |
| 39 | +- There exists a somewhat cleaner/better/faster way of accomplishing the same feature/fix. |
| 40 | +- It does not fit well with some other contributors' longer-term vision for the project. |
39 | 41 |
|
40 |
| -== Releases |
| 42 | +## Releases |
41 | 43 |
|
42 | 44 | Declaring formal releases remains the prerogative of the project maintainer(s).
|
43 | 45 |
|
44 |
| -== Changes to this arrangement |
| 46 | +## Changes to this arrangement |
45 | 47 |
|
46 | 48 | This is an experiment and feedback is welcome! This document may also be subject to pull-requests or changes by contributors where you believe you have something valuable to add or change.
|
47 | 49 |
|
48 |
| -== Heritage |
| 50 | +## Heritage |
49 | 51 |
|
50 | 52 | These contributing guidelines are modified from the "OPEN Open Source Project" guidelines for the Level project: https://github.com/Level/community/blob/master/CONTRIBUTING.md
|
0 commit comments