Issues
When creating an issue keep to following in mind:
We have moved away from Github Issues and are now using Jira Issues to track the work on the project.
In Jira there are multiple issue types to help categorize the work, try to choose the one that is most relevant. If it's not captured in the types, a new one can be created.
Each issue has a description in Jira as to what it should be used for.
It's important that an issue should encapsulate a single change to the project. If an issue is too large then it becomes very difficult for other developers to test. A judgement of size should normally be done when creating an issue, however if when resolving an issue you find that the issue is becoming too large, then split the issue up into more manageable sub issues.
- ✔️ Add unit tests for a one class - isolated change and easy to test - should only change one file
- ✔️ Fix bug in function - A bug fix for a single area of the project
- ✔️ Add a class to check perform a small action - Could grow too large and need to be split up but if it remains in scope this is fine
- ✔️ Implement new output functionality on Webapp - This is an appropriate "Story" issue, but should be broken up into sub-tasks e.g.:
- Implement user output generation
- Implement user output display
- Implement user output error handling
- ✖️ Rewrite Function A and Function B - unless absolutely required this should be 2 separate issues for each rewrite
Issues should be written with enough detail so that anyone can resolve them with minimal input from the developer who created the issue. This can be achieved by ensuring that all the knowledge around that issue is added such as:
- Who raised the issue
- Where the issue is likely to be
- Context around the issue
- How the issue can be reproduced
- How to test that the issue is resolved
- Files that may be required for testing
It won't be possible to give all of this detail for all issues, but we should aim to give as much information as possible
Labels are used on issues to clarify their scope, specify relevant repository, and group them. It is helpful to put which repository the issue creator thinks issue is relevant to by labelling it e.g. autoreduce-frontend for a front-end issue, autoreduce-db for a database issue, etc. An issue may be relevant to more than one repository, and story issues usually will have multiple of those labels.
- You don't have to assign an issue to yourself when you create it!
- Leave issues unassigned and then if you are available to do the issue, assign yourself.
- Avoid assigning other people to issues where possible.
- Avoid having yourself assigned to multiple issues where possible try to have no more than 4 issues assigned to yourself at one time.