Not detecting easy-to-detect incorrect flags

[carriezhengjr]

The command add -p n/Alice e/alice@example.com tag/HR does not provide a warning or error message for the easy-to-detect incorrect flag tag/, where t/ should be the correct flag to use.

According to the module website, "not detecting easy-to-detect incorrect flags (e.g., user entered /t but it should be /tag) is a FeatureFlaw too".

[nus-se-bot]

Team's Response

We do not agree with this assessment as it is not trivial to define what an "easy-to-detect incorrect flag" is.

If tag/ is synonymous to t/, then should tags/ or tag-1/ be allowed too? Similarly, would email/, electronicMail/, or e-mail/ be considered easy-to-detect too?

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

• [x] I disagree

Reason for disagreement: It is stated on the module website under Feature flaws of Guidelines for bug triagling that "Not detecting easy-to-detect incorrect flags (e.g., user entered /t but it should be /tag) is a FeatureFlaw".
This point is applicable to the situation here, because tag/ is usually the most common incorrect flag that users may input instead of the correct t/ flag, and can also be very easily detected.

Furthermore, "easy-to-detect incorrect flags" means possible common input errors. For example, acronyms or 1 letter is used for flags (e.g. n/, e/, t/), but user may still use the full form (e.g. name/, email/, tag/). I believe the module website is not saying that the team should detect all possible incorrect flags like how the team has cited tag-1/ and electronicMail/. Rather, there should be at least some attempt to detect such easy-to-detect incorrect flags, instead of totally neglecting it. This could have been implemented to work in a better way (from the end-user's point of view) without much additional effort.

---