What are the various labels your team or project uses in GitHub or otherwise?

I find myself having a lot of paralysis over choosing labels to use. I'd love some input on the subject.

Comments

[Mikk Pristavka]

Here is our label system more or less in its entirety:
To specify the "type" of the issue: bug, chore, enhancement, feature.

Meta labels that go hand in hand with our GH Project:

• blocked — can't proceed with solving the issue right now due to external factors
• needs review — most of the work and testing is done, the issue is in the "review" column in the project
• needs testing — most of the work is done, but needs testing. also in the "testing" column in the project
• needs work — needs some improvements (usually after testing and/or review). basically the issue is still in progress, but this is to show that it has completed at least one test-review cycle
• on hold — currently not actively worked on, mostly due to other, more critical issues taking priority

Some other organizational labels:

• question — meant for discussion threads
• migration-blocking — specifies PRs that need some manual work before deployment
• issuelist — actual work is done with smaller issues, but overall progress is marked in this generic issuelist using markdown checkboxes.
• wontfix — issues currently not viable to solve or out of scope of the project

We also use issues for non-development tasks and discussion threads, so it makes sense to have the following columns in our Project: TODO (development), TODO (non-development), In progress, Needs testing, Needs review, Done. Issues move from the TODO columns to the right.

We also use the Github issue references and links pretty extensively: All issues mention other related issues in their description (See #123 etc.). Pull requests always mention the issue they close (Closes #123) and the branches also have the issue number as the prefix (123_new_api_feature). This way it's always very easy to find all related issues, discussion threads, pull requests and branches.

[Jake Casto]

Overall we use the same labels. The only difference is we have a label for each member of the team, we enjoy labeling issues by who caused it (or who get's to fix it).

[Mikk Pristavka]

We just assign the people to the issues/PRs -- keeps down the number of different labels as well.

[Damien Cosset]

We have something very simple. For our use cases, we do not need anything very sophisticated.

When we create an issue, we give it a priority label: Priority 1 being urgent and Priority 4 being not important nor urgent.

When someone is working on an issue, that developer gives it the label "In progress". Making sure that nobody does the same thing twice...

Once that issue is solved, the issue is given the "Need Review" label. Self explanatory.

We tried with labels to specify which type of issues it was in our products, but for our small company, it just creates a lot of noise for nothing.

We also use explicit branch naming to help us understanding what it is we are doing. So something like:

Type_Description_Of_Issue_InitialsOfDeveloper

Where Type would be FEAT or FIX for example ( for feature or fix ). Description of issue is either a few keywords to describe the issue or the issue number and the initials to know who coded what.

FEAT_AddingNewTypePayment_DC

That's about as much as we need for our workflow. Simple, direct, quiet.

[Shaunak Pagnis]

Hi Ben! At my workplace, we use Github labels for pull requests quite extensively. And since our GitHub is connected to JIRA, labels come quite handy in navigating through issues.

So we have a process in place where at any given time, a pull request will have two labels, one signifies the category of the pull request and the other the current state of the pull request.

Category based labels are:

• feature
• bugfix
• enhancement
• hotfix/patch

Categories also help us in maintaining the semantic versioning of our product, so before the release, we can just count PRs per category and tag versions accordingly.

And, state-based labels are:

• cooking
• waiting_for_peer_review
• changes_suggested
• waiting_for_merge_review
• ready_for_qa
• ready_for_serving
• served_on_production

[George]

In my current work we use a lot of labels, I believe somewhere in the 20-30 region. Apart from the standard ones provided by github some of them are:

needs review from higher - Before patching or pushing something to the main branch we'll use this to get a senior dev to look over some certain things

George broke it - i tend to break a lot of things

We'll use a lot of our tags to signify what part of the project needs looking into such as AI, Utils, Machine Learning etc

and the common one

Please don't touch otherwise it catches on fire - used way too often

[Kathleen McMahon]

Here's one I add if I don't see it listed: ‘accessibility‘

[Seth Lilly]

It's always bothered me that the wontfix label can't contain the apostrophe so I've started using nope instead.

[Shaurya]

Use will not fix instead.

[Graham Lyons]

'Work in Progress', with a bright red colour, is a useful one. Allows you to open pull requests to get feedback but avoids them being merged by mistake.