nus-se-script
commented
1 year ago Team's Response
This is the intended behavior but we acknowledge that we could update the error messages in future iterations. However, the error message also states that the user can type help for additional assistance.
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [x] I disagree
Reason for disagreement: I disagree with the team's response. Firstly, they have already acknowledged that the error messages can be updated in future iterations, this should make it at least a NotInScope but the team is still trying to reject this bug.
Secondly, typing help will still not solve the issue of the error messages being not informative for the user and it seems like a one size fits all error message pertaining to command.
Thirdly, the module website also supports that the error message not addressing the error which is proven in the issue's screenshots and the below screenshot.
## :question: Issue severity Team chose [`severity.VeryLow`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:** I disagree that this has a severity of VeryLow, this is clearly not a cosmetic bug and it does affect the users usage when they have troubles identifying which part of their input is wrong. However, I update that this should have a severity of **Low** according to the module website on specificity of error message. Below is a screenshot of the bug severity to help dispute against **VeryLow**. 
Describe the bug
Error message provided is not very useful to help the user determine which area requires fixing.
To Reproduce
Steps to reproduce the behavior:
Expected
Error message should let the user know that the first error is due to invalid command while the second error should be due to missing payload input from user to "t/".
Actual
Both error messages are the exact same and it is not very informative to the user.
Screenshots