search

Shauryan123 / pe

0 stars 0 forks source link

Names with d/o not allowed #3

Open Shauryan123 opened 7 months ago

Shauryan123 commented 7 months ago

Steps to reproduce: Command: add Dazy Yong d/o Bella Yong -e dazyyong@example.com -p 97654321 -t johndoe -s Leadership -s C++

Screenshot 2024-04-19 at 4.16.52 PM.png

soc-se-bot commented 7 months ago

Team's Response

Thank you for your bug report. We're correcting the type of the bug to "Feature Flaw" since the functionality is consistent with what's documented in the in-app messages and user guide, which states only alphanumeric characters and spaces are accepted.

Unfortunately, we would still be rejecting this bug under feature flaw since MatchMate only expects nicknames / short names to be supplied, as stated in Page 7 of the user guide:

Pick a nickname if the name is not fully alphanumeric.

Also, according to the course website, they are only considered as feature flaw bugs only if the input is expected to match the legal name of the person, which is not the case in our product.

Therefore, our team's decision would be to mark this bug as not in scope while downgrading its severity to "Low" at the same time, since it's not expected to affect many users (especially when considering only nicknames). Hope that clarifies your concerns.

Items for the Tester to Verify

:question: Issue response

Team chose [response.NotInScope]

Reason for disagreement: In addressing the development team's classification of the inclusion of the "d/o" convention in legal names as NotInScope, I respectfully disagree based on several pertinent observations and established precedents. Firstly, the use of "d/o" (daughter of) and its counterpart "s/o" (son of) are not only common but are also officially recognized in various contexts within Singapore, including legal documentation and educational records. This is substantiated by their explicit mention on multiple authoritative platforms, including educational institutions and government bodies.

Furthermore, the course website itself acknowledges and accommodates such naming conventions, indicating a clear recognition of its relevance and prevalence among the student population. Given that the target audience for our application includes NUS CS students, it is reasonable to assume that a significant portion of this demographic may use or encounter these conventions in either their personal or professional interactions. Ignoring or excluding this convention could lead to issues in user experience and system functionality, particularly in features involving personal identification or data matching.

Therefore, dismissing the "d/o" convention as NotInScope overlooks a crucial aspect of the user's real-world needs and socio-cultural context. The assumption that this convention is irrelevant could alienate users and reduce the practical utility of the application. Hence, I argue that the "d/o" convention should indeed be within the scope of our project to ensure inclusivity and comprehensive user experience design. This adjustment will better align the application's functionality with the documented standards and expectations of its intended user base, enhancing both usability and accessibility.

## :question: Issue type Team chose [`type.FeatureFlaw`] Originally [`type.FunctionalityBug`] - [x] I disagree **Reason for disagreement:** I would like to further emphasize that the issue concerning the "d/o" naming convention represents a significant functionality bug, rather than a mere oversight outside the intended scope of the application. The essence of functionality bugs lies in the application’s failure to accommodate legitimate user behaviors and expected inputs, which in this context, includes the processing of legally and culturally recognized naming conventions such as "d/o." It's imperative to understand that "d/o" and similar prefixes are not only customary but also legally endorsed in many formal settings within Singapore, where our target audience, the NUS CS students, reside and study. These students may input their names in forms and documents exactly as they appear on their official identification, which often includes these prefixes. The application's inability to handle such inputs can lead to user frustration, errors in data handling, and ultimately, a diminished user experience.
## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:** It is of medium severity because it impacts a lot of users following this naming convention.