nus-se-script
commented
3 hours ago [IMPORTANT!: Please do not edit or reply to this comment using the GitHub UI. You can respond to it using CATcher during the next phase of the PE]
Team's Response
It was stated in the UG
The lack of response is an intentional feature to avoid cluttering of the user display. One of the issues with using other products is the clutter of information, and when a response is given for every command, it becomes difficult to parse what is actually going on, especially for tech-savvy users (our user profile). Here is an example:
5 commands gives back an output of 30 lines, about half of which is self-explanatory and serves to clutter feedback for the user. In comparison, we only give feedback when the user requests it.
The aim behind this design choice is to reduce clutter and focus on providing information only to important messages (eg. error messages, feedback that the user wants). Furthermore, this is similar to other command line interfaces, such as the Linux command line. In some/most shells, cd, mv, rm does not give user feedback, but it does give user feedback on error (cannot delete file).
That said, we acknowledge some might prefer this constant user feedback and we could attempt to provide an option for dedicated user feedback. But this is not the issue brought up and would not be in scope for this release.
NotInScope Case: The UG specifies it as not supported or coming in a future version.
Items for the Tester to Verify
:question: Issue response
Team chose [response.NotInScope]
- [ ] I disagree
Reason for disagreement: [replace this with your reason]
Description: On modifying the data, should the application give us some responses? As we may have to
listseveral times in order to check if our command is executed or not Reproduce: Try to execute any validadd,delete,editcommands in a valid manner