We carried out a research about best practice for labels and found out popular and basic labels which are commonly used among git repositories. The list contains labels that you can easily create in your repository and start using right away.   

Scope #

Each label of the scope labels type represents a platform, an underlying technology or a specialization. This type of labels defines to which part of a project the pull request pertains to.

Complexity #

The labels from complexity type define a state of a pull request of having many parts or a difficulty to understand or find an answer.

Feedback #

need comments — a pull request needs an opinion,
discussion — a pull request needs a discussion about the usage, best practice etc.,
question — a pull request has some questions to be answered,
need review — a pull request needs a review from an assigned developer,
need help — a pull request needs a help.

Type #

bug — describes an unexpected or malicious behaviour,
feature — describes a new suggestion that makes a system better,
hotfix — describes a software patches that are applied to a running system in a production status,
improvement — a new suggestion upon an existing feature.

Priority #

P0 — critical, which means the system is not available or major functionality is broken,
P1 — hight, the system is available, but experiencing problems that have a direct impact many users,
P2 — moderate, occasional issue that has been identified and has not affected the system,
P3 — low, minor bug fix or enhancement with small impact,
P4 — informational, general information requests, questions, comments.

Status #

in progress — someone is currently working on a pull request,
paused — a pull request currently is not performed by someone,
duplicate — a pull request that is a duplicate of an existing one,
LGTM — Looks Good To Me,
done — a finished pull request,
reviewed — a reviewed pull request and ready for the next stage,
ready for merge — a pull request is ready for merge by a maintainer,
ready for deploy — a pull request is ready for deploy by a maintainer,
do not merge — do not merge a pull request because there is a problem,
conflicts — a pull request has a conflict and it needed to be resolved before it can be merged,
broken tests — tests that are not passed.

Other to try #

breaking changes are changes of a part of a software that potentially causes other components to fail.

Further Reading #

Go to Customizing Labels to know how to change color of a label.

See how to filter labels on the Filtering Pull Requests by Label page.

Follow the guide Adding New Label to create a new label.

Follow the guide Deleting Label if you have unnecessary labels.