Issue Labels
A custom labelling system was used during the development of this product, as opposed to the default labels provided by GitHub. This helped to promote collaboration in a large team because you have the ability to filter issues based on their labels.
There were four label categories in total.
These labels explain what the issue is about.
Used if the issue is about the current source code including a bug (an undesired behaviour) that needs to be fixed.
Used if the issue is about anything to do with changes in documentation, whether it's related to the code documentation or the wiki.
Used if the issue is about introducing something that adds to the current functionality of the system.
Used if the source code is being modified but the functionality is not affected, i.e. refactoring the source code.
These labels explain how important it is to work on the issue. The priorities are relative to each other.
Used if the issue must be resolved immediately, potentially because there is a bug introduced in the system.
These labels identify the team that owns this issue. Note that if your issue is general (e.g. relating to the wiki), you will not need to include this label.
These labels describe the current status of the issue.
Used if the issue was initially created but then decided that it would not be worked on. In this case, the reason for abandoning the issue should be noted in the comments for documentation purposes.
Used if the issue is available for someone to work on.
Used if the issue cannot be worked on because it is blocked by another issue. In this case, you should comment on which issue it is blocked by.
Used if the issue is completed and linked to a pull request that has been merged.
Used if the issue is currently being worked on by some developers.
Used if the implementation is completed and the changes are currently being reviewed by someone.
Used if the PR was performed and the implementation requires some changes, or if the issue is created but we need to include more details about the issue.