soc-se-bot
commented
4 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]
Names are too restrictive
No special characters are allowed, which could pose problems for some entries with names such as "TImothy s/o Rajesh" or "Bashar al-Assad".
[original: nus-cs2103-AY2324S2/pe-interim#1845] [original labels: severity.Low type.FeatureFlaw]
Their Response to the 'Original' Bug
[This is the team's response to the above 'original' bug]
This is an issue, but not important to the current implementation. This can be added in a future implementation.
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)
- [ ] I disagree
Reason for disagreement: [replace this with your explanation]
## :question: Issue response Team chose [`response.NotInScope`] - [x] I disagree **Reason for disagreement:** The teams response and lack of elaboration indicates that they have overlooked a critical aspect of their product's scope. Their application is meant to be used by "secretaries of a large tech firm" and "has a need to manage a significant number of contacts". In these "large tech firms", there would likely be a diverse group of employees with names of varying formats. As the names of people are the main way in which we identify and address people, it is of utmost importance that the names of individuals are recorded accurately. Even in a local context, we have many people with such symbols in their names. This is something that the team should have been acutely aware of as they built their application. Their value proposition also states that the application should be able to "Categorise people according to their department/origin". A feature that implicitly assumes that the people in the application can be accurately identified. Failing which would defeat the purpose of categorizing people to begin with. As such, I do not believe that this issue is “not in scope”. Accommodating different naming conventions to accurately save individuals into the application should have been one of the main priorities of the group over any additional functionalities that they may have added.
## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:** The team has provided no elaboration on why the severity of my issue has been downgraded. Considering the context in which the application will be used, this issue would cause more than an occasional inconvenience to the user. The secretary would have to come up with ways to remove symbols in employee’s names just to fit their contact information into the application. Furthermore, the removal of symbols that are standard convention may also have the potential to cause confusion. For example, removing the "/" in "S/O" may mislead those unfamiliar with Indian names to think that the father's name or "SO" is a family name. Attached is an extract from a cultural website with information pertaining to Indian names locally. Note the highlighted section.  Considering the limitations and inconvenience that this issue poses, it is deserving of at least a `severity.Medium` label. Sources: https://culturalatlas.sbs.com.au/singaporean-culture/singaporean-culture-naming
This is an issue that can cause quite a lot of inconvenience if the user needs to save names of people with such symbols in their name. In a local context, this can include indian names such as people with "s/o" or chinese people with their chinese names enclosed in brackets