Labels

Justification for labels

Approved

• As a team, for every issue, we need to know that the issue has been decided on and approved by at least two members. This is indicated by two thumbs up, after which the approved label will be added to the issue. This is necessary as there may be some issues which are duplicates or issues which aren't elaborate enough to be worked on. Issues can then be modified as necessary to either expand in scope or depth. Only then are issues approved, and then assigned to be worked on.

Feature

• A feature tag was necessary to indicate whether an issue was relating to new functionality, or whether it was pertaining to some other tagged issue. This helped our team members decide whether they wanted to tackle a particular feature, or if they just wanted to work on documentation/bugs for the day.

Front-end & Back-end

• These labels were useful in order to separate issues for clarity purposes. This allowed each functional sub-team to work on issues that were related to their specific

Documentation

• This tag helped separate code functionality form code documentation and wiki documentation, this helped code reviewers find what they were looking for.

Bug

• This tag often highlights issues which should be of high priority, as they often block other work from happening.

Blocked

• This tag also highlights issues which should be of high priority, it also lets the developers know that the issue cannot be completed without another issue being completed. Inside the issue, there should be a link to another issue/pr which has to be closed first.

Refactor

• This tag lets the code reviewer know that the existing functionality of the code should stay the same, and they should only look for things such as code style, design patterns, etc. No actual functionality should be modified/added in these issues.

Duplicate

• Any duplicate issues were linked to the main issue, and closed with a relevant linked description.