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.
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).
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 factorsneeds review— most of the work and testing is done, the issue is in the "review" column in the projectneeds testing— most of the work is done, but needs testing. also in the "testing" column in the projectneeds 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 cycleon hold— currently not actively worked on, mostly due to other, more critical issues taking prioritySome other organizational labels:
question— meant for discussion threadsmigration-blocking— specifies PRs that need some manual work before deploymentissuelist— 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 projectWe 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 #123etc.). 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.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).
We just assign the people to the issues/PRs -- keeps down the number of different labels as well.