nus-se-bot
commented
2 months ago Team's Response
As specified in the UG, our commands are space-sensitive. If you were to follow the instructions in the edit command exactly, you will be able to run this command. However, we understand that this space-sensitivity can cause inconvenience. Thus, we have also specified fixing this space-sensitivity issue in out planned enhancements.
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [x] I disagree
Reason for disagreement: The team's reasons for rejection are unreasonable for the following reasons.
The commands are neither space-sensitive nor space-insensitive
The team claimed that their commands are space-sensitive which is not the case.
I believe the fourth point in the given image is how the team defines "space-sensitive"
My current issue is that /add-person; name : Colin; phone : 98765435 ; address : Poochie Street 24; email : iampooch@gmail.com does not work because of missing space after add-person.
Notice that the only problem with this command is the missing trailing space after the command keyword. You will see that I added the trailing space for the phone field but omitted the other fields, the command still works (supposed the trailing space exists after the command keyword). This is what I meant by "inconsistent". The current behavior is not even space-sensitive or space-insensitive.
If space-sensitive, the command should not work other than having the format as stated in UG (User Guide)
- The given format in the UG is
/add-person ; name : [name] ; phone : [phone] ; address : [address] ; email : [email]. /add-person ; name : [name] ;phone : [phone] ; address : [address] ; email : [email]/add-person ; name : [name] ; phone: [phone] ; address : [address] ; email : [email]/add-person ; name : [name] ;phone: [phone] ;address: [address]; email : [email]
While many more combinations can be played with, the given 3 formats are equivalent to the one in the UG. I believe this is not the definition of being "space-sensitive".
If space-insensitive, the command should work with or without the spaces surrounding the colons and semicolons.
- The application failed with my given command
The current issue should not be associated with the given planned enhancements
If I am not wrong, the team refers to the first plan.
My current concern is not the downside of being space-sensitive. Hence, the current issue should not be associated with the planned enhancement.
Besides, the team exposed the documentation bugs I failed to capture during the PE. The given command in the DG definitely works based on what I discovered from testing the application, which is an example of my current issue.
The spaces before semicolons are a must for the command keyword whereas optional for fields. This misleads and confuses the user of why the command is unknown.