nus-pe-bot
commented
4 days ago Team's Response
We implemented the capital L this way so that l (small L) will not be confused with I (capital i) for clarity sake
Items for the Tester to Verify
:question: Issue response
Team chose [response.NotInScope]
- [x] I disagree
Reason for disagreement:
For why i feel it is in scope. given that case insensitivity can be easily resolved by changing equals() to equalsIgnoreCase(), i feel that it is a very simple change to make for a better implementation.
Secondly for why i feel it is better implementation: As a user, i am not expecting when sorting to type Price as it feels like a search keyword to me, thus reducing any friction when just trying to sort.
Responding to the teams response, even if they implemented it for the "o/' they did not give any good reason for the part on the field "f/". Secondy, given that in the text book, it says that search keywords (Which the field is, also supported by the screenshot given below from their dg), should be case-insensitive. no where in the dg or ug did they mention about "We implemented the capital L this way so that l (small L) will not be confused with I (capital i) for clarity sake" or the need for case-insensitivity. given that there does not seem to have a significance for the need for capitalisation in this case, i feel that it makes sense to case insensitive field.
## :question: Issue severity Team chose [`severity.VeryLow`] Originally [`severity.Low`] - [x] I disagree **Reason for disagreement:**  given that very low is for cosmetic purposes and that this can cause annoyance when user is trying to sort by field and encounter price not working, and needing to capitalize to Price, it affects usage and can be annoying
Field and order i feel should be case insensitive as they are keywords for me, not like names, abit of a hassle and illogical to follow the case sensitivity. they feel like keywords to me