Writing and contributing to issues

Issue authoring guidelines

For each issue that you want to create, you should write a user story that describes what the issue is, from who's perspective and why we want to work on the issue. Additionally, a set of acceptance criteria should accompany the user story so it is clear when an issue can be closed. An example of this is if we wanted to add a feature (tomato) to our product (a sandwich) then the issue could be worded as the following:

As a sandwich developer, I want to add tomatoes to my sandwich so that the sandwich becomes more delicious

Acceptance Criteria:

the new sandwich now contains tomatoes

Issue tagging

We will be using labels to tag and categorise issues so it is clear which team should work on what issues. The main labels we will be using will be:

• Documentation: Anything related to the wiki, or contributes to the overall documentation of the project
• Good first issue: These issues are related to the initial setup of the project and outline the important information that a new contributor should see
• Enhancement: This tag is for any new feature or request that you want to add to the project (such as the tomato above)
• Bug: This tag is if the issue is reporting a bug. The issue description for a bug is slightly different to the normal user story and is outlined below.
• Frontend: this tag specifies that the issue is related to the frontend team
• Backend: this tag specifies that the issue is related to the backend team

Bug issue authoring

There is an additional section for a bug report that will need to be filled out.

• Description: overview of what the bug is
• Expected results: expected behaviour of the system
• Actual results: what is happening right now in the system because of the bug
• Environment: Local(OS, configs etc) or production
• Steps to reproduce: Outline specifically how you can reproduce the bug (if known)
• Priority level: how severe is the bug and whats the priority to fix it