Skip to content
This repository has been archived by the owner on May 24, 2022. It is now read-only.

Latest commit

 

History

History
131 lines (103 loc) · 9.22 KB

Labelling.md

File metadata and controls

131 lines (103 loc) · 9.22 KB
Raw
title
Labeling

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.

  • A0-pleasereview Pull request needs code review.
  • A1-onice Pull request is reviewed well, but should not yet be merged.
  • A2-insubstantial Pull request requires no code review (e.g. a sub-repository hash update).
  • A3-inprogress 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.
  • A4-clasignoffneeded Pull request requires author to sign off on CLA before review/merge can begin.
  • A4-gotissues Pull request is reviewed and has significant issues which must be addressed. Once addressed, author should relabel as A0-pleasereview.
  • A5-grumble 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.
  • A6-mustntgrumble Pull request has areas for improvement. The author need not address them before merging.
  • A6-revert Pull request that reverts recent changes.
  • A7-looksgoodcantmerge Pull request is reviewed well, but cannot be merged due to conflicts.
  • A7-looksgoodtestsfail Pull request is reviewed well, but cannot be merged due to tests failing.
  • A8-backport Pull request is already reviewed well in another branch.
  • A8-looksgood Pull request is reviewed well.
  • A9-buythatmanabeer Pull request is reviewed well and worth buying the author a beer.
  • A9-FUCKYEAH! 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.

  • B0-patch Pull request should also be back-ported to the beta branch.
  • B1-relnotes 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.

  • F0-consensus Issue can lead to a consensus failure.
  • F1-panic The client panics and exits without proper error handling.
  • F1-security The client fails to follow expected, security-sensitive, behaviour.
  • F2-bug The client fails to follow expected behavior.
  • F3-annoyance 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.
  • F4-tests Tests need fixing, improving or augmenting.
  • F5-documentation Documentation needs fixing, improving or augmenting.
  • F6-refactor Code needs refactoring.
  • F7-footprint An enhancement to provide a smaller (system load, memory, network or disk) footprint.
  • F7-optimisation An enhancement to provide better overall performance in terms of time-to-completion for a task.
  • F8-enhancement An additional feature.
  • F9-meta A specific issue for grouping tasks or bugs of a specific category.
  • F9-release 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.

  • M0-build Building and build system
  • M1-ci Continuous integration
  • M2-config Chain specifications and node configurations
  • M2-installer Installers for macOS and Windows
  • M4-core Core client
  • M5-binaries External binaries (ethkey, ethstore, ethvm, etc.)
  • M6-rpcapi RPC API
  • M7-signer Trusted signer
  • M7-ui User Interface and wallet
  • M8-contracts Solidity smart contracts
  • M8-dapp Decentralized applications
  • M9-deploy Deployment and registration

'P' group

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

  • P0-dropeverything Everyone should address the issue/PR now.
  • P2-asap No need to stop dead in your tracks, however issue/PR should be addressed as soon as possible.
  • P5-sometimesoon Issue is worth doing soon.
  • P7-nicetohave Issue is worth doing eventually.
  • P9-somedaymaybe Issue might be worth doing eventually.

'Q' group

Is used to annotate difficulty of issues.

  • Q0-trivial 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.
  • Q2-easy Can be fixed by copy and pasting from StackOverflow.
  • Q5-substantial Can be fixed by a developer with decent experience.
  • Q7-involved Can be fixed by a team of developers and probably takes some time.
  • Q9-epic 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.

  • Z0-duplicate Issue is a duplicate. Closer should comment with a link to the duplicate.
  • Z0-intended Issue describes a behavior which turns out to work as intended. Closer should explain why.
  • Z0-invalid Issue is invalid. Closer should comment why.
  • Z0-question Issue is a question. Closer should answer.
  • Z0-stale Issue is in principle valid, but it is not relevant anymore or can not reproduced.
  • Z0-wontfix Issue is in principle valid, but this project will not address it. Closer should explain why.
  • Z5-unconfirmed 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?