search

DavidTan0527 / pe

0 stars 0 forks source link

idt field is invalid for add commands #5

Open DavidTan0527 opened 2 years ago

DavidTan0527 commented 2 years ago

Issue

I understand, from the FAQ, why idt is not required. However, also according to the FAQ, the use of idt should not be entirely invalidated.

image.png

soc-se-bot commented 2 years ago

Team's Response

Reject this Bug. We feel that the bug does not have any relation to the implementation of the feature, as the user is still able to CRUD for the idt field. The issue is also unclear in it's explanation, as to what error it is specific to.

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

Reason for disagreement: Apologies for not being clear in my initial bug report. Allow me to reiterate my reasonings:

I understand that idt/ along with all its CRUD works as expected and as specified in the UG. However, my bug report was regarding the design choice of disallowing the idt/ field completely from add.

The attached screenshot from your UG was to contrast your team's justification and my own. Sorry if that wasn't very clear.

From the screenshot of an entry in the FAQ section of your UG, your team argues that "idt/ was intentionally excluded" and "users need not include". This is mostly consistent with your implementation.

My concern is at the "need not include" part (different from cannot include), and that the user should have the choice of entering idt/ with add to avoid the extra step of using edit.

:question: Issue type

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

Reason for disagreement: Currently, your implementation is mostly as expected as per the specifications (excluding the nitpicking of the language choice in the screenshot in the original bug report). Therefore, I would have to disagree with this being a documentation bug.

My report is regarding the design choice of completely disallowing users from using the idt/ field with the add command.

From a convenience standpoint, having to use two commands to achieve what can be done with one, it feels like there could be improvements in the design.

From a feature standpoint, it doesn't hinder the user's usage of the application to solve their needs ultimately but conceptually, using the application, the user is unable to add interview datetime because it is not allowed in add (though technically edit is doing that).

Therefore, add is incomplete in the sense that it completely disallows adding idt/.

:question: Issue severity

Team chose [severity.VeryLow] Originally [severity.Low]

Reason for disagreement: Quoting from the instructions from the module's website:

severity.VeryLow : A flaw that is purely cosmetic and does not affect usage e.g., a typo/spacing/layout/color/font issues in the docs or the UI that doesn't affect usage. Only cosmetic problems should have this label.

severity.Low : A flaw that is unlikely to affect normal operations of the product. Appears only in very rare situations and causes a minor inconvenience only.

The missing feature here doesn't affect the normal operation of the product (through the edit command, the ultimate effect can be achieved) and only causes minor inconvenience (having to use an extra command to add the idt field).

This is not a cosmetic problem, so it would have to, unfortunately, be at least severity.Low.