To facilitate the community in finding ways to contribute that match their experiences and skillsets, we have developed a comprehensive system for labelling issues and PRs. This is an introduction to this standard labelling scheme.
Labels consist of three fields, viz. name, description and color. Label names
should have a consistent format to aid both filtering within the github UI as
well as scanning visually through the list. The following format is the most
suited to this task (where ⎵ denotes a single space):
<emoji>⎵<category>:⎵<name>
Even label names with more than two words in the text should be separated by a
single space ⎵.
An issue has many different attributes:
| Priority color chart | ||||
| Unfavourable | Negative | Neutral | Positive | Favourable |
| #b60205 | #ff9f1c | #ffcc00 | #cfda2c | #008672 |
The priority of an issue is based on its impact, derived from a combination of urgency and importance. This determines the importance of the issue when sprint planning or deciding which issues to tackle next.
| Status color chart | ||||
| Lighter | Light | Medium | Dark | Darker |
| #eeeeee | #cccccc | #999999 | #666666 | #333333 |
The status of the issue determines whether it is ready for work or not. Issues may not be ready to be worked on for a number of reasons and the maintainers must keep updating the labels as the situation evolves.
An issue, at the time of closing can have either the 🏁 status: ready for dev or the ⛔️ status: discarded label based on whether it was closed with or without resolution, respectively.
The goal of an issue is the end-result achieved when the issue is resolved. This represents the impact of the issue on the scope of the software.
The aspect of an issue is the side of the project that the issue deals with. A single codebase can have multiple aspects to it and knowing which ones will be touched helps contributors find relevant issues.
The technical skills a person is required to possess to work on the issue. Skills are a special type of label that vary by repository. Issues may not have a skill tag if no special skills are required.
Issues with interaction labels do not entail any work to be done on the repository. They are for Q&A, RFCs and any other form of discussions. While both of these may appear to be too similar, triage permissions are granted to collaborators who might not have the answers to questions but by labelling them as such, they might draw a faster response from an experienced contributor who does. In the future this category might be rendered redundant by GitHub Discussions and will be removed.
The level of friendliness a particular issue is the valency of the issue towards contributions from the community. Some issues provide a great introduction while others require a little more familiarity with the codebase. These issues do not have the category prefix as two of them are special labels recognized by GitHub. The special ones don't have emojis either.
In the above categories, some are marked with an * sign. Those are mandatory
categories and every issue is required to have at least one label from those
categories.
Only issues labelled with 🚦 status: awaiting triage are allowed to not have all mandatory labels (seeing as they have not been triaged yet).
Categories not marked with an * are optional and it is upto the discretion of
the maintainers to have apply labels from those categories to issues.