Do you know how to use labels for GitHub Issues?

It is important that you, especially a developer, knows how to use labels for GitHub issues when using an open source project on GitHub, as it would help compact issues and make the issue management workflow more efficient. Essentially, having such a predictable workflow will let the community feel professional.

Every new repository comes in with some default labels out of the box that you could use to label your issues to help create a standard workflow in a repository. A list of the default labels and their general uses can be found here: GitHub - Managing Labels

Depending on the project, there is often a need to create labels on top of the default labels. For instance, when you are using an internal project management solution (such as Azure DevOps) for an open source project, a new label "added to backlog" is created and applied to applicable issues specifically for demonstrating that an issue has been added to the Azure DevOps backlog and is being worked on for the community. This way you can give the community an understanding of the current goals of the project and a higher feeling of interactivity with your development team.

Review and clean up labels

You should review the labels regularly and clean up outdated or irrelevant labels to keep the backlog clean and organized. A good use of labels can improve project clarity, enhance communication among team members, and streamline issue prioritization. In contrast, poor management of labels can lead to confusion, misaligned priorities in workflow.

When using YakShaver to create work items, they will be tagged with Needs Refinement, this reminds developers to review the issue to ensure that the details are correct. Once the review has been test passed, ensure that this label is removed, so that other team members know that it ready to be worked on.

When to review a label

• When the label is no longer relevant - For example, removing a "blocked" label after resolving dependencies or unblocking an issue
• If it misrepresents the current state - For instance, removing "need refinement" after the details has been added
• When the issue is closed - Ensure the labels are consistent before closing the issue to maintain an accurate project history
• If the label is unused or duplicated - Remove labels that are not actively used or merge duplicates (e.g. having both label "bug-fix" and "bug")
• When team conventions change - If the team revises its workflow or labeling strategy, update labels to align with the new conventions