search

nus-cs2103-AY1819S2 / forum

CS2103/T discussion forum
6 stars 1 forks source link

On proper tagging of reports for non-bug issues #88

Open s-tr opened 5 years ago

s-tr commented 5 years ago

I would like to seek clarification on how to tag bug reports which don't seem to fall under any of the four type. categories listed:

  1. Completely invalid bug reports
    The user claims that they are unable to do something, however there is an easily found method to do so. For example, my team received a bug report stating that the game is "impossible to play without the User Guide", however it is basically assumed that the user will have access to the User Guide (e.g. typing help)

  2. "Bug reports" which are actually just suggestions
    Some of the bug reports we receive amount to "I think you should do/display [X thing] this way". The closest type is type.FeatureFlaw but the issues listed are not really flaws...

okkhoy commented 5 years ago
  1. Invalid bugs can be rejected, with explanation.
  2. If you think this is a bug, but not very serious, make it low priority and explain why you think so. If you think this is not a bug, reject it and explain why.
s-tr commented 5 years ago

Thank you.

(also, I just re-read the PE rubrics and apparently we're not supposed to post suggestions that are just enhancements, so my team will also follow that)

In addition, if we close a bug in these scenarios as not a bug, do we have to update the severity labels?

okkhoy commented 5 years ago

You can update the severity labels if you want to. If the bugs that are rejected are deemed as valid bugs when the teaching team verifies, the labels will help.