Don't create random labels or edit the existing labels. Please use the labels that are already created in the repository.
Don't simply close the issue after reviewing/processing without assigning a response.* label.
All such issues without a valid response.* label will be treated as response.Accepted, i.e., it is a valid bug on your product.
If you think an issue is a duplicate of another, assign the duplicate label; in addition, you need to specify the original issue using a Duplicate of #___ annotation as explained here.
Assign the type.* label to indicate what type of bug it is.
If there is no type.* label, then such bugs are treated as type.FunctionalityBug.
Attach an assignee to every bug (even the rejected bugs) to indicate who is the owner of the bug.
If there is no assignee, then the responsibility of the bug will be distributed among all the team members (i.e. all team members will lose marks for this).
Please note that you are allowed to change the severity and type of the bug. However, you need to provide an explanatory comment to justify your choice.
Dear students,
Please read the instructions here carefully.
Few things to quickly point out:
response.*
label.response.*
label will be treated asresponse.Accepted
, i.e., it is a valid bug on your product.duplicate
label; in addition, you need to specify the original issue using aDuplicate of #___
annotation as explained here.type.*
label to indicate what type of bug it is.type.*
label, then such bugs are treated astype.FunctionalityBug
.Please note that you are allowed to change the
severity
andtype
of the bug. However, you need to provide an explanatory comment to justify your choice.Thanks, Akshay