nus-pe-bot
commented
1 week ago Team's Response
While some names do include special characters, they can often be omitted or modified without compromising their recognizability or clarity. For instance, in Indian names where slashes (e.g., in "s/o" or "d/o") are commonly used - particularly in Singapore - users can opt for the unabbreviated forms ("son of" or "daughter of") or simply omit these elements.
Though we plan to include such special characters in future iterations but the work to ensure that the parser correctly recognises each flag or name takes much more work that the benefits that it reaps. Thus, making it out of scope.
Items for the Tester to Verify
:question: Issue response
Team chose [response.NotInScope]
- [x] I disagree
Reason for disagreement: This is very much in scope; see below for my full reasoning.
## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:** The target users of this app are therapists (according to your DG):  Therapists will need to store patient details. This includes their **full legal names**. The reason should be obvious - this is in an official medical capacity, and the full legal name should match the name that corresponds to the NRIC/FIN that was entered as that is how it would be in the official medical records of the patient. For the severity, I say `severity.Medium` because there are multiple issues rolled into 1: 1. You are not accepting slashes (common in South Indian names) 2. You are not accepting dashes (hyphenated names are for married couples who want to [join last names](https://www.brides.com/hyphenated-last-name-5069450)) 3. You are not accepting apostrophes (quite common in many countries worldwide like Ireland and Uganda). 4. If you do begin accept slashes, you have not stated how to solve the prefix conflict anywhere in the Developer Guide. These are all issues that prevent a user (i.e. a therapist) from entering the full legal name of many potential patients across Singapore. > the work to ensure that the parser correctly recognises each flag or name takes much more work that the benefits that it reaps. This is not about "benefits" it is about being able to correctly accept the full legal name of a client or patient, since, again, a medical context requires that a therapist/doctor/caregiver knows and keeps track of the full legal name of their patients. Not to mention that the fix is quite simple and requires a single line change (assuming base AB3 structure and decent decoupling of the parser from the prefixes) - just change the prefix for status to something like `st/`
According the [CS2103/T website](https://nus-cs2103-ay2425s1.github.io/website/schedule/week13/project.html):  Due to the above issues your application, by disallowing slashes, dashes and apostrophes, has not reached the quality necessary for a public release. Therefore, the issue is very much in scope.
While this has been noted in the future enhancements section, there is no explanation as to how the problem will be solved. Additionally, as can be seen in the screenshot above there is no explanation as to how the prefix conflict between "s/o" in a name field and "s/" as the status field prefix will be solved.
Again, to exempt a bug from being counted in the PE, it must be under a "Planned Enhancements" section in the DG with details on how the enhancement will be implemented.