This page is to explain the conventions over Parity’s labeling system.
Labels are split into several groups.
- ‘A’ group is used for code-review status and are applicable only to Pull Requests.
- ‘B’ group is used for pull requests for upcoming beta releases.
- ‘F’ group is used to encode the type (and accordingly the severity) of issues; they are applicable only within the Issue Tracker.
- ‘M’ group is to encode the affected component or sub-project.
- ‘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.
All pull requests should start labeled with either ‘A0-pleasereview’, ‘A3-inprogress’, ‘A8-backport’ (in the base of an already-reviewed back-port), or ‘A2-insubstantial’ (should it be an alteration which requires no code review). After review it should be relabeled with another ‘A’ group label.
- Pull request needs code review.
- Pull request is reviewed well, but should not yet be merged.
- Pull request requires no code review (e.g. a sub-repository hash update).
- Pull request is in progress. No review needed at this stage.
A3-stale Pull request did not receive any updates in a long time. No review needed at this stage and should be closed if author does not indicate any further work is done.
A4-awaitingci Pull request is waiting for changes on the CI to complete tests before review/merge can begin.
- 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
- Pull request has minor issues that must be addressed before merging. This may require only replying to comments. Pull request should be relabeled 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 that reverts recent changes.
- Pull request is reviewed well, but cannot be merged due to conflicts.
- Pull request is reviewed well, but cannot be merged due to tests failing.
- Pull request is already reviewed well in another branch.
- Pull request is reviewed well.
- Pull request is reviewed well and worth buying the author a beer.
- Pull request is reviewed well and can not be compensated with any amount of beer in the galaxy ;)
Used on pull requests only. Denotes tasks for the next beta release.
- Pull request should also be back-ported to the beta branch.
- Changes should be mentioned in the release notes of the next major version.
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 panics and exits without proper error handling.
- The client fails to follow expected, security-sensitive, behaviour.
- The client fails to follow expected behavior.
- 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.
F9-meta A specific issue for grouping tasks or bugs of a specific category.
- A specific release. All such issues should be templated on 1387.
Used to denote the affected component or sub-project. Each issue and pull request should have (at least) one.
- Building and build system
- Continuous integration
M2-config Chain specifications and node configurations
- Installers for MacOS and Windows
- Core client
- External binaries (ethkey, ethstore, ethvm, etc.)
- RPC API
- Trusted signer
- User Interface and wallet
M8-contracts Solidity smart contracts
- Decentralized applications
- Deployment and registration
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.
Is used to annotate difficulty of issues.
- Can be fixed by anyone with access to a computer.
Q1-mentor An easy task were a mentor is available. Please indicate in the issue who the mentor could be.
- Can be fixed by copy and pasting from StackOverflow.
- Can be fixed by a developer with decent experience.
- Can be fixed by a team of developers and probably takes some time.
- Can only be fixed by John Skeet.
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 describes a behavior which turns out to work as intended. Closer should explain why.
- Issue is invalid. Closer should comment why.
- Issue is a question. Closer should answer.
- Issue is in principle valid, but it is not relevant anymore or can not reproduced.
- 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.
- Have you tried turning it off and on again?
- Are you fully synchronized?
- Which version of Parity are you running? (“master” or “git” is not a version)
- Which operating system are you running?
- How did you install Parity? (binary, installer, from source, which branch?)
- What flags are you running Parity with?
- Do you use any config file?
- Please, share the exact error message!
- Is there anything in the logs?
- Are you connected to any peers?
- What’s your time? Is it synchronized? time.is
- Did you answer all my questions yet?