Open JamesLiuZX opened 1 year ago
Apologies, but we will be rejecting this bug as it was intended to be this way. 1) Based on the duplicate check on the application, different case names are considered as different people (We admit this is a feature flaw). We intended to allow for the search of case insensitive naming in order to exhaustively display people with the same name regardless of the casing.
2) Furthermore, we provide other prefixes as well to allow the narrowing of scope, whereas the case sensitivity of the name was not one way that we wanted to use to limit the user find experience.
Team chose [response.Rejected
]
Reason for disagreement: First, this(different case sensitivity between how names are stored and how names are queried) is quite inconsistent, and the storing the names in a case-sensitive way like your team has mentioned is a feature flaw.
Second, for parts of names like S/O
in Indian households, your team mentioned in a separate bug report that it should be replaced by SO
for now. However, 'SO' is part of a common last name 'Soh', and Korean last name 'So'. The lack of case sensitivity in find
feature is definitely a feature flaw
, as you can't differentiate between names and parts of longer name strings. Additional examples include Rick
returning people with last name Hendrickson
because rick
is not case sensitive, so it will return substrings within longer strings that are irrelevant. The list can go on for cases that you cannot fully account for during development phase, so case-insensitivity for find is definitely a feature flaw.
In the screenshots below, names are case-sensitive, but finding by names is not. This is unintuitive for the target user (NEA), as if you take the people with same name different cases as different people, then when I want to find the details of a specific person I want to track, many results may be returned, hence reducing my efficiency using the program.