dominic2412 / pe

0 stars 0 forks source link

Compeleteness and Accuracy of the addevent command #4

Open dominic2412 opened 4 days ago

dominic2412 commented 4 days ago

The format of the editevent command currently is documented wrongly and incomplete, the format for the editevent command currently does not enclose optional fields within square brackets ([]). This gives the impression that all fields, such as sp/Sport, t/Faculty, d/Date, v/Venue, and pa/Participants, are mandatory for the command to work. However, in actual, the user could only edit 1 field

command given: editevent 3 sp/Chess

image.png Actual Outcome: the event has been changed, even though the user guide says must provide multiple fields.

To add on, the date and time format are nowhere to be found in the userguide/dev guide the user could only know of the format when the wrong prompt is given, with no examples given

image.png

it could be challenging for users to know what is the correct date

the editevent command also claimed You can remove all the event’s participants by typing pa/ without specifying any participants after it.

but upon testing it, it does not work: image.png

Reason for severity edit event commands in the documentation lack sufficient detail for comprehensive user guidance. Key fields and options are presented with limited examples, leaving users potentially unclear about usage nuances, acceptable inputs, and constraints.

soc-pe-bot commented 19 hours ago

Team's Response

Hi, thank you for the catch.

Two bugs are mentioned:

  1. on the addevent command
  2. on the date and time format

We choose 1 as the bug for this report.

Moreover, readers of this issue should take note that the addevent in the title should be editevent instead according to the description.

We also do think that this bug is of severity medium instead of high, since it does not make the product unusable to users.

Items for the Tester to Verify

:question: Issue type

Team chose [type.FunctionalityBug] Originally [type.DocumentationBug]

Reason for disagreement: Thank you for your response. While I appreciate your clarification and acknowledgment of the issue, I respectfully disagree with the change in bug type from type.DocumentationBug to type.FunctionalityBug. Here is my reasoning:

1. Primary Nature of the Issue:

The issue lies primarily in the documentation, as the User Guide (UG) misrepresents the usage of the editevent command. Specifically: It incorrectly implies that all fields (e.g., sp/, t/, d/) are mandatory, while the app allows editing just one field. It omits essential information about acceptable date/time formats, leaving users unclear about correct input formats.(Likewise for the add command, that is the reason why the title was addcommand but wasn't able to edit due to time constraints) The UG claims that participants can be removed with pa/ (no arguments), but this does not work as described in the app. This inconsistency confuses users about expected behavior. These discrepancies point to errors or omissions in the documentation, not a flaw in the app’s core functionality.

Also, according to the guidelines: type.DocumentationBug includes issues where the UG/DG misrepresents or lacks key information, causing confusion for the user. type.FunctionalityBug applies when the product behavior deviates from the UG or does not meet expected functionality. Since this issue primarily stems from inadequate and incorrect documentation (e.g., missing date formats, misleading examples, incomplete descriptions), it is more accurately categorized as type.DocumentationBug.


## :question: Issue severity Team chose [`severity.Medium`] Originally [`severity.High`] - [x] I disagree **Reason for disagreement:** I also disagree with the severity downgrade from severity.High to severity.Medium. Here’s why: **1. Critical Impact on Usability:** The editevent command is a core feature of the app for managing events. The incomplete and misleading documentation significantly hinders users’ ability to: Use the feature effectively (e.g., unclear input formats for dates). Understand command constraints or optional/mandatory fields. Users may struggle to discover the correct usage through trial and error, leading to frustration and reduced confidence in the app. **2.Guidelines for Severity Levels as per 2103 website:** severity.High: Affects most users and causes major problems, making the product almost unusable. severity.Medium: Causes occasional inconvenience to some users, but they can continue to use the product. In this case: The incomplete and inaccurate documentation affects all users of the editevent command, a key feature. It results in major usability issues that severely impair the app’s effectiveness for event management. Thus, it aligns with severity.High as per the guidelines. In addition, there are No Clear Workaround: Unlike other bugs, users cannot rely on alternative methods or intuitive guessing to address these documentation gaps (e.g., date format errors or participant removal confusion). This further underscores the critical impact of the issue.