nus-pe-script
commented
11 hours ago Team's Response
As these situations are rare, and many apps have only M/F as a standard, we focused our efforts on other areas of the app rather than working on allowing a 3rd (or more) gender option(s). Apart from extra implementation effort, we also did not want to spend extra time and energy debating our perspectives on this since there's a possibility that it could be a contentious issue for some people, and we would rather spend our time debating more significant issues, especially pertaining to the implementation of our new features. Perhaps we will consider your suggestion in future. Therefore, we have marked this as "not in scope".
Items for the Tester to Verify
:question: Issue response
Team chose [response.NotInScope]
- [x] I disagree
Reason for disagreement: Thanks for your response! While I get the team’s rationale to focus on other areas, I respectfully disagree with the idea that this issue is “rare” or low priority. Gender inclusivity is a really important part of modern software design, especially since more people identify outside the binary “M” and “F.” Limiting the gender field to just two options risks excluding a growing group of users who might feel alienated or misrepresented.
A lot of apps these days already include options like “Non-Binary,” “Prefer Not to Say,” or even let users input custom values. Adding something similar doesn’t have to be a massive development effort if done thoughtfully.
I know the team marked this as “Not in Scope” due to resource constraints, but I’d encourage reconsidering it. Inclusivity isn’t just a secondary thought. It’s a necessity for user-centered design.
The gender field does not accept any other inputs apart from "M" and "F". This could limit the accessibility of the application to gender fluid individuals or people who identify as "Non-Binary"