Unable to add a person as both befriendee and volunteer

[JonChong98]

Summary: Trying to add a person as a befriendee, and then as a volunteer results in ElderScrolls rejecting the attempt to add the person as a volunteer. This may be a possible scenario as a person may be acting as both a befriendee and a volunteer (Have seen a scenario like that before in real life where someone was a befriendee but decided to volunteer after some time).

Steps to reproduce:

1. Add a person with valid parameters as a befriendee: add n/TestDupe r/befriendee p/123 e/e@mail.com a/Real home #1.
2. Try to add the same person as a volunteer: add n/TestDupe r/volunteer p/123 e/e@mail.com a/Real home #1.

• Expected: Able to add as a person may act as both roles.
• Actual: ElderScrolls rejects the attempt and displays error message "This person already exists in the address book".

Improvement suggestion: Maybe this behaviour could be allowed? Since the application already requires the user to specify the role of the person using r/ for many commands, there shouldn't be any confusion on whether we're trying to access the person's records as a befriendee or a volunteer.

Screenshot:

[nus-pe-script]

Team's Response

Based on the definition of a volunteer and a befriendee provided in the User Guide's glossary, it is not possible for a contact to be both a volunteer and a befriendee.

According to the CS2103T website, a feature flaw causes the feature to become less useful to the intended target user for normal usage, or designed to work differently from the end-user;s point of view. However, our target users are volunteer managers involved in elderly befriending initiatives, which makes it unfeasible for a person to be both volunteer and befriendee. The target user, volunteer managers, would want not expect a contact to be both the types under any normal circumstances. Therefore, the feature being limited to only one type is indeed useful to the volunteer managers, and is designed to work as intended from the end-user's point of view.

As such, we consider this bug to be rejected.

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

• [x] I disagree

Reason for disagreement: I disagree with the team's stance that it is not feasible for a contact to be both a volunteer and befriendee, and that it is useful for a contact to be limited to only one category.

Take this real life example for instance: https://touch.org.sg/about-touch/stories/2017/07/11/befriendee-turned-befriender-helps-fellow-residents.

Imagine the user of your product is TOUCH Community Services and they are using it to manage volunteers for their TOUCH Community Befriending Program. Mdm Jennifer would first be logged as a befriendee in ElderScrolls and be paired with a volunteer. This is a valid interaction and allows the target user to appropriately track them. They can go on outings together which would be appropriately logged.

Following the article, Mdm Jennifer decides to pay it back by becoming a volunteer herself. But ElderScrolls does not allow this and rejects the attempt to add her as a volunteer.

In such a case, would the usefulness of the app not be diminished for TOUCH Community Services? In the team's response, it was mentioned :The target user, volunteer managers, would want not expect a contact to be both the types under any normal circumstances. Therefore, the feature being limited to only one type is indeed useful to the volunteer managers, and is designed to work as intended from the end-user's point of view.. This goes directly against this particular example, where the target user is exactly as the User Guide has described:

There are more examples of befriendees who have turned into volunteers (a quick google search will give you many results), and the managers in charge of such programs would face a similar situation if they were to use ElderScrolls. In such cases, ElderScrolls would not be able to serve their needs.

But if say the organisation were to try and work around this by removing the contact from the befriendee list and move them to the volunteer list (contact remaining as only one type as mentioned in the team's response), they would be unable to do so if the volunteer and befriendee have logs assigned to them:

The organizer would then have to delete all the logs where the volunteer has interacted with the befriendee in order to facilitate this recategorization. This means the efforts of the volunteer would be lost as their past interactions would no longer be tracked, and the hours for Time Served would be taken away from the volunteer. The organizer will then not be able to accurately track the time served by the volunteers anymore. Would this not also diminish the usefulness of ElderScrolls for the target audience?

If a contact were to be able to be classified as both volunteer and befriendee, the target audience would be able to have their needs met when they face such a scenario and not have to sacrifice data trying to work around the strictly enforced 'one-type' classification of contacts. Would that not be more useful to the target audience?

---