Labels

This website provides the documentation about Labels.

The source data can be found in the ruled_labels folder of the repository. It contains the specs and tests as YAML files. Those files contain:

the list of labels
explanations about the label codes (the first letter)
the logic ruling whether a set of labels is valid or not

Those rules are processed by ruled_labels and all rules must be satisfied.

Last updated: 2024-09-06 07:45 - commit cb0da11d…

Respositories

Label Documentation for the repo `paritytech/polkadot-sdk`

This document is generated automatically based on commit cb0da11d and was last updated on 2024-09-06T07:45:21Z.

The source data can be found in the ruled_labels folder of the repository. Those rules are processed by ruled_labels and all rules must be satisfied.

Description

This is the documentation for paritytech/polkadot-sdk version v0.0.2. It contains 42 labels and 3 rules.

Import on 2023-08-26

Rules

Require at least one topic
- require: {"!some_of":["T*"]}

Allow only one difficulty label
- when: {"!some_of":["D*"]}
- require: {"!one_of":["D*"]}

Enforce R0-silent
- when: {"!some_of":["A1"]}
- require: {"!all_of":["R0"]}

Labels

`A␣` - Action: Used with GHA and trigger a certain process.

A0-needs_burnin: Pull request needs to be tested on a live validator node before merge. DevOps team is notified via matrix.
A1-insubstantial: Pull request requires no code review (e.g., a sub-repository hash update).
A2-stale: Pull request did not receive any updates in a long time. No review needed at this stage. Close it.
A3-backport: Pull request is already reviewed well in another branch.
A4-needs-backport: Pull request must be backported to all maintained releases.

`C␣` - Contrubution: Labels used for contributions.

C1-mentor: A task where a mentor is available. Please indicate in the issue who the mentor could be.
C2-good-first-issue: A task for a first time contributor to become familiar with the Polkadot-SDK.

`D␣` - Difficulty: Difficulty of the issues, also used for contributions.

D0-easy: Can be fixed primarily by duplicating and adapting code by an intermediate coder.
D1-medium: Can be fixed by a coder with good Rust knowledge but little knowledge of the codebase.
D2-substantial: Can be fixed by an experienced coder with a working knowledge of the codebase.
D3-involved: Can be fixed by an expert coder with good knowledge of the codebase.

`I␣` - Issues: Categorisation of issues.

I0-panic: The node panics and exits without proper error handling.
I1-security: The node fails to follow expected, security-sensitive, behaviour.
I10-unconfirmed: Issue might be valid, but it's not yet known.
I2-bug: The node fails to follow expected behavior.
I3-annoyance: The node behaves within expectations, however this “expected behaviour” itself is at issue.
I4-refactor: Code needs refactoring.
I5-enhancement: An additional feature request.
I6-meta: A specific issue for grouping tasks or bugs of a specific category.
I7-duplicate: Issue is a duplicate. Closer should comment with a link to the duplicate.
I8-wont_fix: Issue might be invalid or this project will not address it. Closer should comment why.
I9-optimisation: An enhancement to provide better overall performance in terms of time-to-completion for a task.

`R␣` - Release: Used for creating the release notes.

R0-silent: Changes should not be mentioned in any release notes.
R1-breaking_change: This PR introduces a breaking change and should be highlighted in the upcoming release.

T0-node: This PR/Issue is related to the topic “node”.
T1-FRAME: This PR/Issue is related to core FRAME, the framework.
T10-tests: This PR/Issue is related to tests.
T11-documentation: This PR/Issue is related to documentation.
T12-benchmarks: This PR/Issue is related to benchmarking and weights.
T13-deprecation: The current issue/pr is, or should be, part of a deprecation process.
T14-system_parachains: This PR/Issue is related to system parachains.
T15-bridges: This PR/Issue is related to bridges.
T16-async_backing: Issues related to asynchronous backing.
T17-primitives: Changes to primitives that are not covered by any other label.
T2-pallets: This PR/Issue is related to a particular pallet.
T3-RPC_API: This PR/Issue is related to RPC APIs.
T4-runtime_API: This PR/Issue is related to runtime APIs.
T5-host_functions: This PR/Issue is related to host functions.
T6-XCM: This PR/Issue is related to XCM.
T7-smart_contracts: This PR/Issue is related to smart contracts.
T8-polkadot: This PR/Issue is related to/affects the Polkadot network.
T9-cumulus: This PR/Issue is related to cumulus.

Last updated: 2024-09-06 07:45 - commit cb0da11d…

FAQ

You may see labels defined as S0-design. It is made of a label code: S, a number: 0 and some description. The rules **only apply to the part of the label without the description and the label above will simply be considered as S0. Should the description change, the rules would remain unaffected.

What are rules ?

Rules are defined in a YAML files and describe:

the name of the rule
the conditions of the rule (for instance, some rules only apply if a specific label is present)
the conditions for a set of labels to be valid. For instance, you will not be able to have C1-low and C5-high for a given PR. You will have to chose one or the other and the rules will enforce this

Labels

Respositories

Label Documentation for the repo `paritytech/polkadot-sdk`

Description

Rules

Labels

`A␣` - Action: Used with GHA and trigger a certain process.

`C␣` - Contrubution: Labels used for contributions.

`D␣` - Difficulty: Difficulty of the issues, also used for contributions.

`I␣` - Issues: Categorisation of issues.

`R␣` - Release: Used for creating the release notes.

FAQ

How is a label interpreted ?

What are rules ?

Where can I find the source of the rules ?

Are there tests to check those rules ?

Where can I report issues/doubts I have about some rules ?

What happens when rules fail ?