Skip to content
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.

Improve contribution guidelines #13902

Merged
merged 1 commit into from
Apr 28, 2023
+10 −3
Merged

Improve contribution guidelines #13902

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 10 additions & 3 deletions docs/CONTRIBUTING.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -36,10 +36,11 @@ A Pull Request (PR) needs to be reviewed and approved by project maintainers unl
*Process:*

. Please tag each PR with exactly one `A`, `B`, `C` and `D` label at the minimum.
. When tagging a PR, it should be done while keeping all downstream users in mind. Downstream users are not just Polkadot or system parachains, but also all the other parachains and solo chains that are using Substrate. The labels are used by downstream users to track changes and to include these changes properly into their own releases.
. Once a PR is ready for review please add the https://github.com/paritytech/substrate/pulls?q=is%3Apr+is%3Aopen+label%3AA0-please_review+[`A0-please_review`] label. Generally PRs should sit with this label for 48 hours in order to garner feedback. It may be merged before if all relevant parties had a look at it.
. If the first review is not an approval, swap `A0-please_review` to any label `[A3, A5]` to indicate that the PR has received some feedback, but needs further work. For example. https://github.com/paritytech/substrate/labels/A3-in_progress[`A3-in_progress`] is a general indicator that the PR is work in progress.
. PRs must be tagged with their release notes requirements via the `B*` labels. If a PR should be mentioned in the release notes, use `B1` and add either: `T0-node`, `T1-runtime`or `T2-API` - this defines in which section of the release notes the PR will be shown.
. PRs must be tagged with their release importance via the `C1-C7` labels.
. PRs must be tagged with `B*` labels to signal if a change is note worthy for downstream users. The respective `T*` labels should be added to signal the component that was changed. `B0-silent` must only be used for changes that don't require any attention by downstream users.
. PRs must be tagged with their release importance via the `C1-C7` labels. The release importance is only informing about how important it is to apply a release that contains the change.
. PRs must be tagged with their audit requirements via the `D1-D9` labels.
. PRs that introduce runtime migrations must be tagged with https://github.com/paritytech/substrate/labels/E0-runtime_migration[`E0-runtime_migration`]. See the https://github.com/paritytech/substrate/blob/master/utils/frame/try-runtime/cli/src/lib.rs#L18[Migration Best Practices here] for more info about how to test runtime migrations.
. PRs that introduce irreversible database migrations must be tagged with https://github.com/paritytech/substrate/labels/E1-database_migration[`E1-database_migration`].
Expand All @@ -50,7 +51,13 @@ A Pull Request (PR) needs to be reviewed and approved by project maintainers unl
. PRs should be categorized into projects.
. No PR should be merged until all reviews' comments are addressed and CI is successful.

*Reviewing pull requests*:
*Noting relevant changes:*

When breaking APIs, it should be mentioned on what was changed in the PR description alongside some examples on how to change the code to make it work/compile.

The PR description should also mention potential storage migrations and if they require some special setup aside adding it to the list of migrations in the runtime.

*Reviewing pull requests:*

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:

Expand Down