Labels

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.

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.

Good first issue

• Good for newcomers looking to make their first contribution. Issues will tend to be easier to pick up and help the assignee learn the codebase.

Sub-team Labels

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. Group 1 has added labels for Payments, Flats and Chores to associate issues with the area of functionality. This will help teams for each area be able to focus on their specific issues.

Front-end & Back-end

• These labels specify if the issue / PR is associated with front-end or back-end code.

Payments

• Issues that relate to payments, such as allowing users to make payments or add payments.

Flats

• Issues that relate to flat members, such as creating flats or adding users to flats. This also includes issues that relate to account/users functionality.

Chores

• Issues that relate to chores, such as adding chores or tracking chores.