Labelling

This page is to explain the conventions over Parity's labelling system.

Labels are split into 5 groups.

'A' group is used for code-review status and are applicable only to Pull Requests.
'F' group is used to encode the type (and accordingly the severity) of issues; they are applicable only within the Issue Tracker.
'P' group is to denote priority. They are generally relevant only to issues, though may in principle be used on pull-requests.
'Q' group is to denote difficulty.
'Z' group are reasons for why something is a non-issue. They are applicable only within the Issue Tracker.

As such, a pull request must have a single label from the 'A' group and may additionally have a single label from the 'P' group (though typically will not).

An valid issue must have a single label from the 'F' group and may additionally have a single label from the 'P' group. An invalid issue should be closed with a single label from the 'Z' group.

'A' group

All pull requests should start labelled with either 'A0-pleasereview', 'A1-inprogress', 'A7-backport' (in the base of an already-reviewed back-port), or 'A9-insubstantial' (should it be an alteration which requires no code review). After review it should be relabelled with another 'A' group label.

Pull request needs code review.
Pull request is in progress. No review needed at this stage.
Pull request requires author to sign off on CLA before review/merge can begin.
Pull request is reviewed and has significant issues which must be addressed. Once addressed, author should relabel as A0-pleasereview.
Pull request is too large. It should be broken down into smaller PRs; when reduced in size PR may be relabelled as A0-pleasereview.
Pull request has minor issues that must be addressed before merging. This may require only replying to comments. Pull request should be relabelled as A0-pleasereview to get a final sign-off from a reviewer.
Pull request has areas for improvement. The author need not address them before merging.
Pull request is reviewed well, but cannot be merged due to conflicts.
Pull request is already reviewed well in another branch.
Pull request is reviewed well.
Pull request is reviewed well, but should not yet be merged.
Pull request requires no code review (e.g. a sub-repository hash update).

'F' group

Issues should have only one of these. Do not combine; if multiple labels are equally applicable to an issue, use the one with the lowest number.

Issue can lead to a consensus failure.
The client fails to follow expected, security-sensitive, behaviour.
The client fails to follow expected behaviour.
The client fails to build on a supported platform.
The client behaves within expectations, however this "expected behaviour" itself is at issue. Annoyances are small enhancements which dramatically improve the usability of the client.
Tests need fixing, improving or augmenting.
Documentation needs fixing, improving or augmenting.
Code needs refactoring.
An enhancement to provide a smaller (system load, memory, network or disk) footprint.
: An enhancement to provide better overall performance in terms of time-to-completion for a task.
An additional feature.
A specific release. All such issues should be templated on 1387.

'P' group

Typically used only to annotate issues, however P0 and P2 may reasonably be used on PRs in exceptional circumstances.

Everyone should address the issue/PR now.
No need to stop dead in your tracks, however issue/PR should be addressed as soon as possible.
Issue is worth doing soon.
Issue is worth doing eventually.
Issue might be worth doing eventually.

'Q' group

Used to annotate difficulty of issues

'Z' group

Used only on issues which will (or may, in the case of Z5) be closed immediately.

Issue is a duplicate. Closer should comment with a link to the duplicate.
Issue is invalid. Closer should comment why.
Issue is a question. Closer should answer.
Issue is in principle valid, but this project will not address it. Closer should explain why.
Issue might be valid, but it's not yet known.