Github Issues and Label Conventions - mini/git-brunching GitHub Wiki

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 3 types of issues

  • Feature requests - To request a feature being added to the project
  • Bug reports - To report a bug
  • Misc Requests - A general purpose issue, but generally used to request changes to the project workflow, repo settings, or maintenance.

The issue life cycle looks like this:

  1. Create the issue using one of the three 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. The label "needs-review" will be removed if it is ready to work on.
  3. Once approved, the issue is assigned to a developer to work on. The issue should be added to the Project "Main" in order to automatically keep track of its life cycle.
  4. Work is done on the issue
  5. Once a pull request is opened (referencing the issue that was worked on via a keyword such as "closes #3") and merged, the issue is automatically closed and has been completed
  6. Celebrate!

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

Because 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.
  • Don't solve multiple issues at a time - consequentially, your PR should only reference one issue.
  • 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.
  • You can always tag people in the comments of an issue!

Labels

There's 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. Backend - a feature/bug that is to do with the backend.
  2. Frontend - a feature/bug that is to do with the frontend.
  3. Bug - the issue details a bug report.
  4. Documentation - the issue details a change to documentation OR to the repository set up.
  5. Duplicate - the issue has been market.
  6. Enhancement - the issue details a feature request.
  7. Good first issue - the issue is a good one to start off with!
  8. Needs-review - the issue has not been reviewed yet and may require
  9. wont-fix - The issue is low priority and won't be worked on.
  10. ci/cd - The issue details a request for ci/cd changes
  11. URGENT - The issue is urgent and needs to be reviewed/worked on as soon as possible.
  12. testing - test automation tasks.
  13. t_bug - test automation related issue.