- Using Yetto
- Labeling issues
- Searching issues
- Commenting on issues
- Mentioning others in issues
- Assigning issues
- Cross-referencing issues
GitHub issue labels are a simple but powerful tool. In code repositories, they are often used to categorize the purpose or state of issues – for example, "bug" or "feature request". When you use Yetto to communicate with users about support issues, labels can help you filter your searches. For more information, see "Searching issues".
Labels can be added to issues to give additional context to the support ticket. Some more general context that is often useful mimics the default "bug" and "feature request" labels used by code-specific projects. A few example labels that you may want to add to your project include:
Problem- This can be used to indicate that a user has encountered a problem with your product. It may be a bug or a known issue, but it requires some research to resolve.
Question- Not all support requests involve problems with the product. Many come from people who need some help figuring out how to use it properly. This label is also useful for reviewing every month or so to determine what documentation you may be missing.
Feature request- Users always have additional features they'd like to see. With this default label, you and your team can filter through these every so often to get a feel for how people are using your product and what would make it better.
Yetto- This is added by default to all Yetto issues, so that you can search for or filter out those issues, in cases where the repository is used for situations other than external support requests.
Many teams support multiple products, or multiple features within the same product. Adding labels to issues to further categorize them by product or feature make it easier to work through similar issues with less context switching. This makes the work faster, but it also helps you and your team find common causes to problems when you see them in one place. The specific labels will depend heavily on the product and features you are supporting, but here are a few examples that may give you some inspiration:
Billing- Any product that people pay for will eventually have billing issues.
Docs- Your documentation is another product that you offer. Keep the docs in mind when going through support requests, and label issues when you think a problem or question could be avoided in the future with better documentation.