Issues

There are 3 types of issues:

• Feature requests - To request a feature be added to the project
• Bug reports - To report a bug
• Documentation - To request more documentation be added to the project

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 add more labels and 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 and the "approved" label will be added.
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 ensure that the information is in enough detail (i.e. the acceptance criteria explains exactly what is expected if someone were to take on this issue). In the case of a bug, you should also check that it actually exists and that the issue isn't 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 and unimportant features.
• Don't solve multiple issues at a time in a single pull request (theoretically, your pull request should only reference one issue).
• You can always tag people in the comments of an issue!

Labels

Add any labels here.