Volunteer & Org Admin Workflow Differs By Activity Type

[tonysurma]

This is a new direction/change in functionality to support requirements found during testing to increase value of application for users

Campaign Workflow Differs By Activity Type

please note these names are not great and we will come up with better ones - or at least we hope to :8ball:

Type A: Activity Managed

example: Smaller event without shifts or broad timeframe such as volunteering to host a discussion group for few hours after work hours For this type of Activity the following is true:

• [ ] Tasks are not shown to volunteers
• [ ] Volunteers volunteer for Activities
• [ ] Admins assign tasks to volunteers
• [ ] NO assignment communication is sent to Volunteers and thus do not get option to accept/reject
• [ ] Reminder sent ahead of Activity with option to respond as 'no longer able to volunteer'

  Type T: Task Managed

_example: Preparedness Awareness event with shifts across a full day or two_For this type of Activity the following is true:

• [ ] Tasks are shown to volunteers
• [ ] Volunteers volunteer for Tasks
• [ ] Admins can re-assign tasks to volunteers
• [ ] Re-assignment communication is only sent to Volunteers when it results in change outside of assigned timeframe and they can accept/reject task assignment
• [ ] Reminder sent ahead of Activity with option to respond as 'no longer able to volunteer'

  Type D: Deployment Managed

example: Smoke Detector Installations at many addresses across 2 days For this type of Activity the following is true:

• [ ] Tasks are shown to volunteers
• [ ] Volunteers volunteer for Tasks - example: "'Tony' volunteers for 'Tuesday Driver'"
• [ ] Admins can re-assign tasks to volunteers
• [ ] Re-assignment communication is only sent to Volunteers when it results in change outside of assigned timeframe and they can accept/reject task assignment
• [ ] Reminder sent ahead of Activity with option to respond as 'no longer able to volunteer'
• [ ] Task Assignments, across Tasks, are grouped into Deployments
• [ ] Deployments are a group of assignments which create teams delivery specific work to a specific target as identified by a name of Deployment (string) - example: "'Tony' assigned to 'Tuesday Driver Task' and 'Bill' assigned to 'Tuesday Installer Task' are grouped into Deployment 'Install Smoke Detector at 1313 Mockingbird Lane'
• [ ] Volunteers on Tasks can be in multiple Deployments and Deployments can have multiple Volunteers on Tasks grouped in them

[mmoore99]

@MisterJames I would be willing to develop an initial cut at a list of tasks for implementing the above discussed scenarios. Please advise as to whether, or not, you would like for me to proceed. Thanks.

[MisterJames]

@mmoore99 Each of those above would likely be one (or more) tasks. I think to approach these, we'll be best to tackle each as a separate issue with a corresponding PR. If we need a couple of PRs, we can work from a common feature branch.

If you want to map some of it out, that would be great...an issue for each point above (just reference this issue in your new one to create a link).

[mmoore99]

@MisterJames I would propose adding the following sub-issues:

1. Add "ActivityType" property to "Activity" model to support requirements in #504
2. Add support for "Type A: Activity Manged" activities as defined in #504
3. Add support for "Type T: Task Manged" activities as defined in #504
4. Add support for "Type D: Deploymnent Manged" activities as defined in #504

For each of these sub-issues I will begin to map out a more detailed list of the specific tasks that need to be done as well create a list of questions/discussion points.

[mmoore99]

@tonysurma @OhMcGoo (cc: @BillWagner @mheggeseth @MisterJames) I have been working on flushing out the tasks needed to implement the changes to the Activity workflows for issues #506, #507 & #508 (sub issues of this issue). In this process I have developed a list of questions that I think would be best addressed by the "users" of the application. Your feedback on the following questions would be very helpful (there will probably be more to come :smile:):

• When volunteering for an activity the sign in dialog is pre-populated with the user's email and phone number (which have previously been confirmed), but they are allowed to change these values. Should they be able to be changed? If changed, do they need to be confirmed as well?
• Should the app restrict the number of volunteers allowed for an activity or task to the number specified in the "NumberOfVolunteersRequired" property of the activity/task? If so, is there a need to allow for some type of "overflow" mechanism such as having a "MaximumNumberOfVolunteers" property for an activity/task or an overflow list?
• Should the lists of activities/tasks somehow indicate whether not not volunteers are still needed? If so, should there be a way to filter the list of activities/tasks to only show activities that still need volunteers?
• No communication is to be sent to volunteers when an admin assigns the volunteer to a task. However, is it correct that a confirmation email would still be sent to the volunteer upon volunteering or unvolunteering from an activity as per PR #500 for #372?
• Currently the app allows admins to assign/unassign volunteers to tasks, but there does not seem to be a way for an admin to "unvolunteer" a volunteer from an Activity. Is this a requirement?
• Currently, in order to assign or un-assign users to/from tasks the admin must enter each individual task from the tasks listed on the admin ActivityDetails page. Would it be beneficial to enhance the ActivityDetails page to allow for "expanding " each task to show the assigned users and perhaps provide ability for admin to drag and drop a user from one task to another, eliminating the need to enter each specific task?

[jim-mcgowan]

@mmoore99 and @misterjames: I'm out of the office until Tuesday but will review this when I return and provide feedback. Thanks!

[jim-mcgowan]

These are great questions, @mmoore99! First, let me say that some of my comments may contradict direction provided elsewhere. I hope that @tonysurma and @BillWagner will be able to clarify where needed.

When volunteering for an activity the sign in dialog is pre-populated with the user's email and phone number (which have previously been confirmed), but they are allowed to change these values. Should they be able to be changed? If changed, do they need to be confirmed as well?

Answer: I don’t feel that anyone should be able to sign-up for an activity without completing a brief profile. See the http://www.chicagocares.org/ as an example of how site visitors can view event details but when they want to sign-up without having signed in, they are offered a Login/Register page. Thus, displaying an editable phone number field doesn’t seem to make sense.

Should the app restrict the number of volunteers allowed for an activity or task to the number specified in the "NumberOfVolunteersRequired" property of the activity/task? If so, is there a need to allow for some type of "overflow" mechanism such as having a "MaximumNumberOfVolunteers" property for an activity/task or an overflow list?

_Answer: Again, referring to http://www.chicagocares.org/, they offer a the opportunity to be placed on a waiting list: _

Should the lists of activities/tasks somehow indicate whether not not volunteers are still needed? If so, should there be a way to filter the list of activities/tasks to only show activities that still need volunteers?

Answer: Yes and yes. See the screenshot, above, which shows spots remaining as “0.” In addition “full” activities are “grayed” in their Calendar view.

No communication is to be sent to volunteers when an admin assigns the volunteer to a task. However, is it correct that a confirmation email would still be sent to the volunteer upon volunteering or unvolunteering from an activity as per PR #500 for #372?

Answer: I think receiving an e-mail when volunteering or unvolunteering for an activity should be a user-selected preference. That said, having the ability to generate Admin-sent messages with activity details - whether automatic or manual - should be possible, say, a few days before the activity.

Currently the app allows admins to assign/unassign volunteers to tasks, but there does not seem to be a way for an admin to "unvolunteer" a volunteer from an Activity. Is this a requirement?

Answer: Yep! Especially for those volunteers who aren’t tech savvy or “call to cancel.”

Currently, in order to assign or un-assign users to/from tasks the admin must enter each individual task from the tasks listed on the admin ActivityDetails page. Would it be beneficial to enhance the ActivityDetails page to allow for "expanding " each task to show the assigned users and perhaps provide ability for admin to drag and drop a user from one task to another, eliminating the need to enter each specific task?

Answer: I like it!

[mmoore99]

@tonysurma @OhMcGoo @BillWagner @mheggeseth @MisterJames @dpaquette

Proposal

In @OhMcGoo's answers to my questions above he indicated that it would be preferable for the app to have the ability to restrict the number of volunteers for an activity/task to the number of "required" volunteers. He also indicated it would be nice for the app to have the ability for a volunteer to be put on a "waiting list" if the activity/task has met its requirement for volunteers. Since I am in the process of writing the code for issues #506, #507 and #508 which deal with the new activity workflows it would be a good time to incorporate these changes as well.

I would propose that we provide an option at the Activity level to specify whether volunteer limits would be enforced for the activity and any of its subordinate tasks. Specifically:

• Add two boolean properties, IsLimitVolunteers and IsAllowWaitList to the Activity and Task models. These two properties would appear on the add/edit dialog for the Activity. The IsAllowWaitList property would only be visible and settable if the IsLimitVolunteers is true. All subordinate tasks would inherit their settings for these properties from the parent Activity.
• If IsLimitVolunteers is true:
  • Lists of activities/tasks would display the number of volunteers needed/signed up and provide some visual indication (color change, etc) as to whether the activity/task is full. Also, activity/task lists would be filterable to allow for only showing activities/tasks that are not full.
  • If the task/activity is full and "IsAllowWaitList" is false, no signup button will be displayed
  • If the task/activity is full and "IsAllowWaitList" is true, a signup button will be displayed. However, when the user clicks the signup button a dialog will be displayed informing the user that the activity/task is full and asking them to confirm whether they want to be added to the wait list.
• If IsLimitVolunteers is false:
  • Lists of activities/tasks would not distinguish as to whether the activity/task is full
  • Signup buttons would be displayed for all activities/tasks and there would be no restriction as to the number of volunteers that could sign up for a activity/task.

Please respond back with your thoughts. If there are no objections I will include these changes in the code for the above mentioned issues.

[tonysurma]

I will review as part of next milestone

[mmoore99]

@tonysurma the approach described in my "proposal" above was implemented in PR #523.