Labeling - Wiki OpenEthereum Documentation

This page is to explain the conventions over OpenEthereum’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.

‘A’ 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 A0-pleasereview.
• 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 ;)

‘B’ group

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.

‘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 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.

‘M’ group

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

‘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

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.

‘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 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.

Issue-Checklist

1. Have you tried turning it off and on again?
2. Are you fully synchronized?
3. Which version of OpenEthereum are you running? (“master” or “git” is not a version)
4. Which operating system are you running?
5. How did you install OpenEthereum? (binary, installer, from source, which branch?)
6. What flags are you running OpenEthereum with?
7. Do you use any config file?
8. Please, share the exact error message!
9. Is there anything in the logs?
10. Are you connected to any peers?
11. What’s your time? Is it synchronized? time.is
12. Did you answer all my questions yet?