nus-pe-script
commented
1 year ago Team's Response
This is only a cosmetic issue and does not hinder the user's ability to use the program and hence the severity is lowered to very low
The 'Original' Bug
[The team marked this bug as a duplicate of the following bug]
Blank spaces in front of module names not handled if edit through the storage file
As an advance user, I would like to edit the text file in the storage space. As seen in the first image, i added blank spaces in front of the module name to see if it was handled by the application. The first image shows that the module with blank spaces in front was successfully accepted by the application and the
list /allshows the module name with blank spaces in front.Justification: Since this is just a slight inconvenience for me as an advance user, this bug is listed with low severity.
[original: nus-cs2113-AY2223S2/pe-interim#1205] [original labels: type.FunctionalityBug severity.Low]
Their Response to the 'Original' Bug
[This is the team's response to the above 'original' bug]
We accept this bug as we do not handle the extra white spaces. However, this is mostly a cosmetic issue that does not affect the functionality of the program and hence we are lowering the severity to very low
Items for the Tester to Verify
:question: Issue duplicate status
Team chose to mark this issue as a duplicate of another issue (as explained in the Team's response above)
- [x] I disagree
Reason for disagreement: I disagree with the developers stance of marking this issue as duplicate.
It is apparent that these two issues, though seemingly similar, pertain to distinct functionalities and should be treated as separate bugs.
This duplicated report references a problem with the name.txt file, while the original bug concerns the modules.txt file. Given that name.txt is responsible for storing names and modules.txt for storing modules, it is evident that these files serve different purposes and impact separate functionalities within the application. As a result, the issues associated with these files should not be considered duplicates.
From a developers point of view, I completely understand that it is crucial to maintain an organized and efficient bug tracking system. However, marking issues affecting different functionalities as duplicates can lead to oversights and hinder the effective resolution of the identified problems.
In conclusion, I disagree with the developers stance of marking this issue as duplicate.
## :question: Issue severity Team chose [`severity.VeryLow`] Originally [`severity.Low`] - [x] I disagree **Reason for disagreement:** The developers stated that this is mostly a cosmetic issue that does not affect the functionality of the program. I disagree with this reasoning that it is a cosmetic issue and would like to maintain my Low severity rating due to the reasons stated below: **Inconsistency in handling blank spaces**: When the addition of blank spaces was done in the application, the blank spaces were handled gracefully. However, it fails to handle them correctly when the same edit was done on the name.txt storage file. This inconsistency indicates a potential oversight that warrants attention, as it affects my experience when using the application. Furthermore, if in the future this name is required to be used on other parts of the program, it could cause potential issues as well due to the blank spaces. **Negligent in storage feature importance**: By lowering the severity to Very Low, it creates an impression that the developers are not prioritizing the storage feature and the user's perspective when editing storage files. The storage feature is a crucial component of the application and should be treated with due importance. Furthermore, in their User Guide, they did not provide any steps for the user on how to edit their storage file. They just gave a warning telling the users not to edit the storage file. This further strengthens my argument that the developers is treating the storage feature as non-importance, or is trying to hide underlying issues when it comes to editing the storage files. Hence, I disagree with the developers changing this bug rating to VeryLow as this issue is not just purely cosmetic, and I would like to keep my original severity of Low.
If I am a normal user, and were to add my name with blank spaces at the front of the text, the blank spaces at the front was removed.
As an advance user, I would like to change my name from the storage file, but if I add spaces at the front of my name, it was shown in the output welcome message as well.
Justification: This doesn't hinder my usage of the app, just a slight inconvenience if I am an advance user. Hence, the severity is tagged as low.