search

cth06-Github / pe

0 stars 0 forks source link

Command got cut off in the user guide #12

Open cth06-Github opened 1 week ago

cth06-Github commented 1 week ago

image.png

^In this case, the parameters of the edit command is cut off (the tag), which may mislead users

nus-pe-bot commented 4 days ago

Team's Response

No details provided by team.

The 'Original' Bug

[The team marked this bug as a duplicate of the following bug]

Example Use Case in UG is not consistent

Description: Example use case states "This command adds John Doe instantly, tagged as a volunteer." but it does not add the described contact

Steps to reproduce: Copy paste the command into the command line

Expected: The contact is added with the tag volunteer

Actual: The contact is added without the tag volunteer

image.png

image.png

[original: nus-cs2103-AY2425S1/pe-interim#2733] [original labels: severity.Low type.DocumentationBug]

Their Response to the 'Original' Bug

[This is the team's response to the above 'original' bug]

No details provided by team.

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)

Reason for disagreement: Although the root cause of the issues raised in both bug reports is likely to be the same, I chose to disagree that it is a duplicate because given the insufficient information provided, the point of contention could be, and seems to be, different.

My bug report points out that the edit command format in the user guide is incomplete (because the part on tags is not shown (i.e. cut-off)), but the original bug report is referring to an inconsistency noticed in an example use case provided in the user guide.

What the original bug report wished to describe, based on my interpretation, is that the developer gave a use case example in which XX should happen after YY command is executed, but instead, ZZ occurred. In this case:

Due to the inconsistency between expected and actual (i.e., the expected does not match the actual), this is a documentation bug with low severity. In the original bug report, there was no mentioning of why there is such an inconsistency, understandably so because it could either be:

  1. Command in the User Guide got cut off, thus it was an incomplete command. (When users use an incomplete command and the command passes, the actual will naturally be different from the expected). OR
  2. Command in the User Guide is correct, but the description of the Expected case was wrongly written

However, my bug report was referring to the command format of the edit command being wrongly indicated in the User Guide. This is nothing related to "Example Use Case in UG is not consistent". The issue I wish to point out in that bug report is that there seems to be "cut-off" for the edit command format. I.e. edit command format is not written in full.

The user guide wrote edit INDEX [n/NAME] [id/STUDENT_ID] [i/INDUSTRY] [p/PHONE] [e/EMAIL] [a/ADDRESS] but it should be edit INDEX [n/NAME] [id/STUDENT_ID] [i/INDUSTRY] [p/PHONE_NUMBER] [e/EMAIL] [a/ADDRESS] [t/TAG]… where [t/TAG]... was missing.

If there was a response or any indications that the developer team acknowledge that the original issue was due to the commands written being cut-off, thus the issue, then I think the bug report I raised can be marked as a duplicate because at its core, the root cause is the same, just that it occurred in different context, despite the fact that the original bug report would be referring to the command used being written wrongly while I am referring to the command format being written wrongly. Regardless, I am however unable to tell how the developer team interpret the original bug report. If the developer team interpret the original bug report as the command written in the user guide was correct but the description of the use case is wrong, then the bug report I made is definitely not the same as the original bug report.

Given that it is unclear what exact problem the developer team has identified that is causing the issue reported in the original bug report, and that the original bug report was referring to use case inconsistency rather than whether a command format is written correctly (two different things here), it is best for me not to assume and thus I would choose to say that my bug report is not a duplicate of the original bug report.