Incorrect commands in UG

[gskang-22]

todo TODO_NAME /tag TAG_NAME deadline DEADLINE_NAME /by DATE_TIME /tag TAG_NAME

For many of your commands, some input arguments are optional (ie tags). However, it is not stated inside your UG. This would give the impression that these parameters are compulsory, especially since your use cases almost always contain a tag parameter, forcing users to input a tag parameter even when they do not wish to do so. Perhaps the arguments should have been surrounded with [] to indicate they are optional, or it should have been stated somewhere inside the UG.

[nus-se-bot]

[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

Thank you for the bug report. After reviewing your feedback, we have determined that the issue is classified as NotInScope for this version and the severity is VeryLow instead of Low. Below, we provide a detailed explanation of our rationale:

Issue Explanation:

• The /tag parameter is optional for commands such as todo and add. This is clearly reflected in the application's behaviour and documentation provided through the help command, sample outputs, and examples. However, the User Guide does not explicitly state that /tag is optional, which may lead to the impression that it is required for these commands.
• Since the omission in the User Guide is addressed through other means, such as in-app help and examples, users are still sufficiently informed, and the application behaves as intended.

Why This Is Not a Bug:

1. Documentation in Help Command:

   • The help command provides accurate information about the usage of /tag. It explicitly mentions that /tag is optional, as shown below:

     

     

2. Consistency in Behaviour:

   • The sample commands and outputs also demonstrate that /tag is optional. For example:

     Add Patient Command:

     Sample Output:

     • add Alice /tag HighPriority: Adds a patient with a tag.
     • add Bob: Adds a patient without a tag.

     This consistency shows that /tag is not mandatory and the application behaves as intended.

3. Alignment with PE Guidelines:

   • According to the PE bug triaging guidelines, "nitty-gritty details missing from the UG is not a bug as the user is informed of those details using other means such as error messages or in-app help."

   • Since /tag being optional is explicitly stated in the help command and demonstrated in the examples, the omission in the User Guide does not qualify as a bug:

     

Justification for NotInScope:

• Fixing this issue would involve explicitly stating in the User Guide that /tag is optional for all commands where it applies. However:
  • This is already well-documented in other parts of the system (e.g., the help command and examples).
  • Adding this information to the User Guide would duplicate information already available elsewhere and potentially clutter the documentation without providing significant value.
• As this issue pertains to improving documentation rather than addressing functionality, it is classified as a Quality of Life improvement and is therefore NotInScope for this version.

Justification for VeryLow Severity:

1. No Impact on Functionality:

   • The omission of explicit mention in the User Guide does not affect the core functionality of the application. Users can still perform commands successfully with or without /tag.

2. Alternative Sources of Information:

   • The optional nature of /tag is discoverable through the help command, examples, and sample outputs, which provide sufficient documentation.

3. Minimal User Confusion:

   • Since the system provides multiple sources of documentation and examples, the likelihood of confusion is extremely low. Any misunderstanding can easily be resolved by referring to the help command.

4. Alignment with Guidelines:

   • The issue aligns with the PE guidelines, as minor details missing from the UG do not constitute a bug when they are communicated through other reliable means.

5. Quality of Life Improvement:

   • Adding explicit mention in the UG would be a minor improvement, but it does not resolve a critical issue or significantly enhance the user experience.

Based on these points, the issue is reclassified from Low to VeryLow severity as it poses no functional impact and only affects documentation clarity.

Conclusion:

The omission of /tag being optional from the User Guide is not a bug as users are sufficiently informed through other means, such as the help command and examples. The system functions as intended, and the documentation aligns with PE guidelines. Thank you for your feedback, and we will consider this suggestion for future improvements.

Items for the Tester to Verify

:question: Issue response

Team chose [response.NotInScope]

• [ ] I disagree

Reason for disagreement: [replace this with your reason]

---

## :question: Issue severity Team chose [`severity.VeryLow`] Originally [`severity.Low`] - [ ] I disagree **Reason for disagreement:** [replace this with your reason]

---