jessicawyz / pe

0 stars 0 forks source link

UG examples being invalid for project names, causing behavior to deviate from UG example #15

Open jessicawyz opened 2 months ago

jessicawyz commented 2 months ago

image.png

image.png

various instances of CS2103T_TP used as project name, which is not allowed by the add function.

image.png

nus-pe-script commented 2 months ago

Team's Response

No details provided by team.

The 'Original' Bug

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

'CS2103_TP' given as valid project name in the user guide

Note from the teaching team: This bug was reported during the Part II (Evaluating Documents) stage of the PE. You may reject this bug if it is not related to the quality of documentation.


Just discovered that the 'CS2103_TP' is widely given (about 18 instances found using ctrl-f in the user guide pdf) as the project name throughout the user guide which will hinder the users' usage as the app only allows alphanumerics as input.


[original: nus-cs2103-AY2324S2/pe-interim#312] [original labels: severity.Medium type.DocumentationBug]

Their Response to the 'Original' Bug

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

Valid bug, but the severity should be low. The examples in the the user guide are there to give more clarity to the user what to put into the placeholder. Users are not asked to use the exact example in the user guide (using the example without ensuring a project with the same name as the example is in the project list would prompt another error anyway). Thus, the possibility that this would prevent the user from using any command is low, and the severity should be set as low.

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: [replace this with your explanation]


## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.High`] - [x] I disagree **Reason for disagreement:** I disagree with the severity label, I think this should be a severity medium after I looked at the other bug and the duplicate bug. Similar to the other bug that involves set deadline for project and tasks. Now this documentation bug also impacts assign team command. The number of commands that is impact is quite broad (as pointed out by the other tester there are 18 instances) I think overall it will decrease the trustworthiness of the UG and hinder the user as at least 3 commands now do not have a guaranteed success example. Justification for the other two commands' severity are pasted below. Examples in UG serve the purpose of asking users to try out according to the examples and are expected to be successful such that users can create their own versions that are correct. Furthermore, testers test according to the UG and the behavior of the app is definitely expected to align with that advertised by the UG. It is true that using the commands directly will prompt another error of project not found. But users will naturally (like what I did) try to add another project with the name 'CS2103T_TP' and then realize it is infeasible, following that users are not provided a valid example for these commands that has guaranteed success to try out. This causes setback and confusion to users using that app, thus I believe the severity should be medium, also the same as the duplicate test report's original label.