rui-han-crh
commented
1 year ago Team's Response
Decision
Rejected
Reason for Rejection
The naming of the tags is really up to the user, not the application, to decide. David Li's tag is meant to signal that this person is a family member who is also a part of our organisation.
This is also sample data, the user is free to modify any of these kinds of data if they want, it's unrelated to any features.
The tester is suggesting that we block certain tags from being entered because they don't fit the scope of the project. We have to disagree with this as it will certainly minimise the usability and flexibility of tags and the application.
In fact, if we did, doing so may even be a form of Overzealous input validation.
The ability to accept anything as a tag word opens up the use of the software to many more potential audiences other than the one we are targeting, and restricting the tag phrases does not add much usefulness.
There is actually nothing wrong with David Li being a part of the organisation, but happens to also be our family member.
Because this isn't a flaw of a feature, because it is only the sample data being loaded as an example, and this suggestion does not increase usability of the tags feature, we are rejecting this issue.
Duplicate status (if any):
--
According to the User Guide, "SectresBook helps secretaries to maintain all the information of the members of their club by collating a list of identifiable information, past records, loan amounts and future tasks".
Perhaps SectresBook can impose restrictions on the naming of texts so that they align more with the context of clubs, ie: having a person with tag "family" by default, seems out of context.
[original: nus-cs2103-AY2223S1/pe-interim#3036] [original labels: type.FeatureFlaw severity.Low]