search

telferang / pe

0 stars 0 forks source link

Unable to see list of food using list-food #6

Open telferang opened 1 week ago

telferang commented 1 week ago

Screenshot 2024-11-15 165634.png

Screenshot 2024-11-15 165557.png

According to the user guide, I will be shown a list of food. However, I am unable to see a list of food despite adding food earlier

soc-se-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]

Food entries also not being shown when the command list-food is used

Steps to reproduce

add-food orange 200 list food

Expected outcome

Here is your food intake list: 1. orange (200 calories) at 15/11/2024 17:32:01

Actual Outcome

Food Entries for 2024-11-15: Total daily Calories: 0

Screenshot

bug 10.png

[original: nus-cs2113-AY2425S1/pe-interim#615] [original labels: type.FunctionalityBug severity.High]

Their Response to the 'Original' Bug

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

Thank you for taking the time to bring this to our attention. We can replicate this and acknowledge that this missing functionality is a issue likely to impact some users. However, upon consideration, we believe that this bug only merits a Medium severity, as opposed to High.

We believe this as per the reporting guide, a High severity bug is one that "makes the product almost unusable for most users.". We believe this statement is untrue as the advertised focus and design consideration of our program was to make an effective exercise and training tracker to prepare users for their NAPFA test - not to track users food intake. Calorie/Water intake management is described in both the UG and DG as an additional functionality that may provide some self-motivated benefit to users who choose to use it, as it only provides listing functionality and doesn't tie in to other systems by design. Therefore, as a secondary design consideration / partially out-of-scope addition that doesn't directly influence the main functionality of the program, we believe that losing access to food-reporting functions only impacts the targeted userbase in the way suggested by a Medium rating - as an "inconvenience" faced by some users, who can still use the program for it's intended and advertised purpose.

We appreciate your help and time spent making our program more robust and bug-free.

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.Medium`] Originally [`severity.High`] - [x] I disagree **Reason for disagreement:** Thank you for acknowledging that the bug is valid. However, I must point out that the UG and DG **did not** specify that Calorie/Water intake management is an additional functionality or secondary feature. After reviewing both documents, I found no mention of terms such as "main," "additional," or "motivated" to suggest that these features are optional or of lower priority. I hope I am not wasting my time addressing a justification that appears to have been made up to lower the severity. Nevertheless, in the event that I am mistaken, I will assume that Calorie/Water intake management is an additional functionality as mentioned in UG/DG. Firstly, the argument that severity should be judged based on the developer’s intended functionality seems flawed. By that logic, should all bugs in the exercise and training tracker be classified as High severity simply because it is considered the "main" feature of the program? This reasoning does not align with how we should assess the severity of bugs. Issues should be classified based on their real-world impact rather than their perceived importance in the development cycle. Even if the feature were intended as an additional functionality, that does not imply it is insignificant or unlikely to be used by most users. In fact, it is very reasonable for **most** users to frequently use Calorie/Water intake management as part of their fitness tracking, especially since it is described as part of the program’s capabilities. Therefore, the bug’s impact should be reassessed based on how it affects the overall user experience and the program's advertised functionality. If we were to accept the reasoning that a feature bug’s severity can be reduced by labeling it as "not the main functionality," it sets a concerning precedent. Teams could game the system and justify downplaying issues in any feature by arbitrarily designating it as “additional” or secondary, even if it is critical to users. For features included and described in the UG and DG, users naturally expect them to work as intended, regardless of their internal classification. As such, severity should reflect the real-world impact of the issue, not whether the team views the feature as “main” or “additional. Finally, given that all users are currently unable to use the list-food feature, its severity should be classified as High since it effectively renders part of the program nonfunctional.