Improve contribution guidelines (#13902)

Author: bkchr

docs/CONTRIBUTING.adoc

@@ -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`].
@@ -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: