Github Conventions

To contribute to this project, you need to learn about issues and labels, and how they're used to drive work in this project!

Issues

There are 4 types of issues:

• Bug report - Create a report to help us improve this project
• Documentation update - Updates to any documentation or administrative aspects of the project
• Feature request - Suggest an idea for this project
• Refactor request - Refactoring existing functionality in the project

The issue life cycle looks like this:

1. Create the issue using one of the four templates. Labels will be automatically added, but you may need to configure them if they're more specific.
2. Wait for the issue to be peer-reviewed and approved. This project will use the two thumbs up rule, where if the reviewer approves, they will thumbs up the issue. The second person to thumbs up will change the label waiting for approval with approved.
3. Once approved, the issue is assigned to a developer to work on. The issue should be added to the Project SOFTENG750 Project: Wedium in order to automatically keep track of its life cycle.
4. Work is done on the issue
5. Once the work is done on the issue, a pull request (which references the issue that was worked on via a keyword such as closes #3) should be created. Before the work is merged into master and the issue is closed, 2 code review approvals are required and the necessary tests (in the GitHub Action) must pass. Once these are complete, the issue will be automatically closed and the work is complete.
6. Celebrate 👏

What makes a good issue, and what should I look for while reviewing?

Since issues are created using a template, you typically don't need to do much! The issue author has the responsibility to fill out the information required for the issue to be accepted. However, you should check that the bugs are actually existing, and that the issue isn't currently duplicated.

Important Notes:

• Don't work on issues that aren't assigned to you.
• Check whether or not the issue has been approved to work on before self assigning it! The review process is important to filter out false bugs/duplicates/non-important features.

Labels

There are 11 types of labels, and understanding them is important to know what type of work it is, who can work on it, and how high priority it is.

1. approved - Approved for development
2. blocking - Issue blocks future/current development
3. bug - A bug found within a feature of frontend/backend
4. do not approve - An issue that has been reviewed and unapproved
5. do not merge - A pull request that has been review and unapproved
6. documentation - Improvements or additions to documentation
7. duplicate - An issue or pull request already exists
8. feature - Addition of a feature
9. refactor - Restructuring existing code to improve code quality
10. waiting for approval - Approval of an issue is required before starting
11. won't fix - This issue will not be worked on