Descriptions of labels for GitHub issues

We have discussed how to build a community around an open source project and what is the best way to communicate with community members. There are many tools available, e.g. mailing lists, discussion groups or chats but we selected GitHub as it provides many opportunities and tools. It seems unnecessary to provide many different communication tools because they may scatter the community members. Instead, we decided to have one common place for everyone where the entire community can work together, communicate and develop.

Labels [categories]

GitHub has may useful tools that are used by us and our community. Issues are one of the most important tools because they provide many possibilities. We decided to group them into categories in order to better understand them. These categories have many advantages, e.g. if an issue is labeled, it means that we read it. Additionally, categories organize issues, so if a developer wants to see all bugs that are in the system, he filters only these issues marked as a bug.

Announcement

Announcements are added mainly by YetiForce team and are used to inform GitHub community about important events related to the project. We will use this category to inform about new versions of the system and important safety notices. Important information will be also published in other places but GitHub will be our primary platform for communication with our community, so if someone wants to be up-to-date with the system, all necessary information can be found there.

Question

This category will mark issues that are questions from users, administrators or YetiForce developers. Not only our team will provide answers to various questions, but other users will also reply to them, however, their knowledge of the system might be at various levels. Gathering people with various experience allows to look at the issue from a wider perspective and the responses can complement one another programming-wise as well as business-wise. We encourage the community members to help each other because then our team will have more time to develop the system.

Bug

We verify each issue and if we confirm that a described problem exists in the system, we will label it as a bug. Developers take care of bugs but we also encourage all community members to send us ready-made patches. This way everyone can help to create the system that is less prone to failure and, in the meanwhile, YetiForce developers will have more time to boost the development of new functionalities.

Enhancement

This category will contain issues that describe new functionalities or suggest improvements of tools that already exist. It also indicates that our team will soon take care of this issue because it appears to be important to us or we have already planned adding the same or similar functionality.

Discussion

Issues with this category require some discussion or indicate that the community has a different point of view than YetiForce, so all advantages and disadvantages can be exchanged here and everyone will have an opportunity to express their own opinion.

Ignored

It means that YetiForce will not take care of this issue.

Labels [subcategories]

More info required

This label means that an author of an issue needs to provide more details. YetiForce team will precise which information is required. If an issue doesn’t have all necessary data, we will ask you to read an article, which explains what kind of data is required in order to proceed with an issue.

High priority

Issues that have high priority are of great importance to us and our team will take care of them before other issues.

Verification required

This label indicates that an issue needs to be additionally verified on the programming level.