volunteer sign-up pages, task assignments as workflow

[Chris]

We need to figure out how people will sign up as volunteers, and how
that offer itself becomes a node that others can negotiate an
"interview", and either accept or reject. If accepted, they get added
to that role, and work starts to flow to them

[Kiran Vaka]

Below is one way of doing this:

1. There will be 'User Groups' for each of the volunteer categories. Example: 'Change Detection', 'Drupal Integration' etc. These are similar to the present user groups like 'Authenticator', 'Organizer', 'Dispatcher'. Each of the user groups will be have it's own set of access permissions which will apply to all users / volunteers within that group.

2. Prospective volunteers fill up the volunteer sign-up form. This form will include a list of tasks they can work on (change detection, drupal development etc.), out of which they have to select one ( or multiple if you wish to allow that). Each task corresponds (is mapped) to a User Group.

3. Who will be doing the "interview"? Is the admin, or another user? The person who will be doing this will belong to a User Group within the workflow. Example: UserGroups called 'CDetection Admin', 'Drupal Admin'

4. Once the above form is submitted (and verified that this user has not been rejected previously), a 'User' object is created (a new node in Drupal terms). This object has a 'Status' field which is set as 'Pending' or 'Requires Approval'. The object has a 'Role' field which is 'Change Detection' / 'Drupal Integration' etc. 

5. The new user object is automatically 'linked' or 'assigned' to the admin (need Drupal developers' inputs on how this can be implemented) who will be involved with the interview process, based on certain criteria (assign to different people depending on value of 'Role' field). Automatic notifications will be sent out to that person.

Example: 

Request came in from prospective 'Change Detection' volunteer -> Form Filled - Status='Pending', Role='Change Detection' -> User Object created -> Assigned to CDetectionAdmin1 (a user belonging to 'CDetection Admin' group) -> Automatic notification sent to CDetectionAdmin1

6. An admin user, on logging in, can see on his dashboard a link saying 'Volunteer Requests', and on clicking can easily see all the people whose volunteer requests have been assigned to him.

7. Once interview is finished, the admin can change the 'Status' field value from 'Pending' to either 'Approved' or 'Rejected'. This action will send out an automatic notification to the person associated with that record (his email id will be stored within)

If Approved : 

a) The user will obtain all the permissions associated to the user group of his Role. Example: If he requested as Change Detection volunteer, he will obtain the access permissions to the websites, forms which enable him to perform this task.

b) He becomes part of the Workflow process for his Role (change detection, drupal development etc. - we yet have to design them), and will be assigned tasks automatically.

Let me know if this would be sufficient for the volunteer sign-up, and please also give any suggestions for possible enhancement/changes for the above. I also request the Drupal developers to think in terms of the modules required for implementing this. Feel free to email or contact on skype for further discussion.

Regards,

Kiran

Skype: kiran.waka

[Greg]

The workflow makes sense, but can't this be a set of Google Docs
spreadsheets? Concerned we make a lot of work just to get started...

You could have a Drupal Webform volunteers fill in, export the results
as a CSV straight in to a Google spreadsheet only available to the
group admins/project leads. Then the admins can mark up the people in
their group as they see fit. You also have the advantage of not
enforcing a set of fields on people when we don't really know what
they want yet. If it's a spreadsheet, admins can add a column to the
end if they find they need to store some additional data. If it turns
out nearly everyone wants that additional data and it should be
collected at source, add a new field to the Webform. If, later, a
common set of fields emerges and this becomes a Drupal app, you can re-
import the spreadsheet data from your Webforms and Google spreadsheets
to nodes. There are modules for that. =)

On the sign-up form side, I think we should ask volunteers to dedicate
a number of hours per week or per month they *know* they can provide,
a serious commitment, and encourage them to be pessimistic. Otherwise
you could end up with a large list of people but no idea how many
hours a month that equates to when you're planning your software
development. It's no good staring at a list of 40 names and thinking
"wonderful, that's at least 400 hours of development time", when in
reality it's about 80 hours. Or maybe 800 hours! Who knows? You need
to...

Also, just an addition view of mine, important to shield volunteers
from all the project noise. I've noticed nothing gets done if too many
people are involved in the discussion. Volunteers get caught up in the
discussion and put things off indefinitely, awaiting a solid decision
that may never come. The discussion needs to happen elsewhere.

The volunteers need to get organised tasks and a deadline to achieve
them by, according to how many hours they said they could dedicate
(e.g. no point giving a 12 hour task to someone who said they can give
1 hr a week). Deadlines are important, otherwise people won't do it.
The message being "great, help us, but only if you really can!" It's
not good volunteering to help, being assigned a task and then not
doing it (or not doing it quick enough).

To illustrate what I mean, once a Drupal developer has been through
the process and marked "accepted" in a groups staff sheet, they can be
allocated a task, estimated to take a similar amount of time the the
amount they said they could give, with a deadline reflecting that. If
the deadline slips and contact with the volunteer is lost, or it's
clear the volunteer hasn't actually done anything, the task goes to
someone else and they are marked as "missing" or something like that,
until such time as they put their hand up again. If they do that three
times, no more tasks. Sounds harsh, but I've seen the most basic tasks
assigned to people and sit around for WEEKS on these volunteer
projects. Volunteers with the best intentions can be really damaging
if they take tasks and don't do them.

That's my thoughts. Hope it's helpful.

On Jan 30, 12:39 pm, Kiran Vaka <kiran.v...@gmail.com> wrote:
> Below is one way of doing this:
>

> 1. There will be *'User Groups' for each of the volunteer categories*. *
> Example*: *'Change Detection', 'Drupal Integration'* etc. These are similar

> to the present user groups like 'Authenticator', 'Organizer', 'Dispatcher'.
> Each of the user groups will be have it's own set of access permissions
> which will apply to all users / volunteers within that group.
>

> 2. Prospective volunteers fill up the *volunteer sign-up form*. This form

> will include a list of tasks they can work on (change detection, drupal
> development etc.), out of which they have to select one ( or multiple if you

> wish to allow that).* Each task corresponds (is mapped) to a User Group.*

>
> 3. Who will be doing the "interview"? Is the admin, or another user? The
> person who will be doing this will belong to a User Group within the

> workflow. *Example: UserGroups called 'CDetection Admin', 'Drupal Admin'*

>
> 4. Once the above form is submitted (and verified that this user has not
> been rejected previously), a 'User' object is created (a new node in Drupal

> terms). This object has a *'Status' field which is set as 'Pending' *or
> 'Requires Approval'. The object has a *'Role' field which is 'Change
> Detection' / 'Drupal Integration' *etc.
>
> 5. The new *user object is automatically 'linked' or 'assigned' to the admin
> * (need Drupal developers' inputs on how this can be implemented) who will

> be involved with the interview process, based on certain criteria (assign to
> different people depending on value of 'Role' field). Automatic
> notifications will be sent out to that person.
>

> *Example: *
> *Request came in from prospective 'Change Detection' volunteer -> Form

> Filled - Status='Pending', Role='Change Detection' -> User Object created ->
> Assigned to CDetectionAdmin1 (a user belonging to 'CDetection Admin' group)

> -> Automatic notification sent to CDetectionAdmin1*

>
> 6. An admin user, on logging in, can see on his dashboard a link saying
> 'Volunteer Requests', and on clicking can easily see all the people whose
> volunteer requests have been assigned to him.
>

> 7. Once interview is finished, the admin can *change the 'Status' field
> value from 'Pending' to either 'Approved' or 'Rejected'.* This action will
> send out an *automatic notification* to the person associated with that

> record (his email id will be stored within)
>
> If Approved :
> a) The user will obtain all the permissions associated to the user group of
> his Role. Example: If he requested as Change Detection volunteer, he will
> obtain the access permissions to the websites, forms which enable him to
> perform this task.

> b) He *becomes part of the Workflow process for his Role* (change detection,

> drupal development etc. - we yet have to design them), and will be assigned
> tasks automatically.
>
> Let me know if this would be sufficient for the volunteer sign-up, and
> please also give any suggestions for possible enhancement/changes for the
> above. I also request the Drupal developers to think in terms of the modules
> required for implementing this. Feel free to email or contact on skype for
> further discussion.
>
> Regards,
> Kiran
>

> *Skype: kiran.waka*

[Chris]

my thought was threads each of these threads spins into its own wiki
page.

Chris

[James Wilson III]

It sounds like a possible candidate for implementation would be to use standard real drupal User accounts (instead of the notion of atomic, managed User Objects). And extend the standard Drupal 'registration form'  as the volunteer application sign-up, offering a list of Organic Groups (OG) to which to sign-up for and then some custom glue modules in combination with Trigers/Actions/Rules modules (the defacto "workflow" modules of Drupal 6) to hold it all together.

A couple questions would need to be answered: 

Is there a need to track conversations just among approved applicants, and track the conversation/thread online? (this would be one benefit of using OG).

Is there anything against your 'user object'  being implemented as a regular Drupal user account, and the 'volunteer sign-up form being in actuality the drupal registration form' that the real applicant creates? This implies that once a user registers, they will have their own account they are in charge of, and once they are approved and get the confirmation email, they will later use to log into the system to view their groups'  discussion threads/wikis  etc. 

Drupal has inbuilt support for 'administrator approval' for new users, and OG probably has some extent of an administrator approval to join a group as well. We could add any additional rules (such as conditional email notifications to group owners based on the applicant's choice while filling out the registration form).

Some secondary thoughts on implementation: 

is it feasible that a potential applicant would volunteer and take on multiple roles in multiple groups? We could limit this in the registration/application form, but by default, once your a real Drupal user, you can apply to 'join'  any number of user groups...  a programmer would have to write custom validations to limit this.

James

[Kiran Vaka]

The concept of Organic Groups (OG) looks promising here - each of them being a Selective group requiring approval by the group administrator, before the User (new volunteer) becomes a member. 

As Greg mentioned appropriately, too many volunteers involved in any discussion may lead to indecisiveness and delay, hence we can impose a maximum sign-up limit on the OG; the volunteer trying to sign-up is automatically given the message if no places are available. However, for example, if 2 positions are left, then more than that number can sign-up and be in 'pending' mode, until the Admin approves only 2 of them (after interview). 

Also, as he mentioned, an additional field in the sign-up form will be the 'Time' they can dedicate per week. In addition, a "Time Track" method for volunteers and admin to keep track of each person's time spent, automatically compare the total time spent weekly by the volunteer against the value he mentioned in his record, if it falls below (say more than 3hrs) send an automated 'time not met' message to the volunteer and admin; if this repeats for 2 consecutive weeks, then make that position available for a new volunteer. If all this can be automated with minimum intervention from the OG Admin, it will be great. If this 'time track' requires too much implementation, then we can get started without this; on a long haul though, this is highly desirable. 

<< Is there a need to track conversations just among approved applicants, and track the conversation/thread online? >>

The conversations/discussions related to the project definitely need to be available for the other volunteers in the group, the group admin and owner.

<< is it feasible that a potential applicant would volunteer and take on multiple roles in multiple groups? >>

It is feasible, but again in line with what Greg mentioned, it is better for a volunteer to complete his few selected tasks properly rather than being over-optimistic and having incomplete tasks in many projects. Hence a maximum limit can be imposed on the number of groups he can join. In fact, if there are a lot of volunteers signing-up for each of the groups, then it is advisable to restrict each volunteer to one group only.

Also, regarding the sign-up forms / Drupal registration form, since different Roles or Groups (Drupal Integration, Translation, Change Detection etc.) often require different unrelated skill sets from volunteers, it is feasible to have sign-up form showing different input fields for different OGs selected? Example: If the initial value to be selected is Role, and 'Translation' is selected, then we have to show a field which asks 'Creole - Yes/No' or 'French - Yes/No'. However these are not required if he selects 'Drupal Integration' - where we might instead have to ask 'Drupal Exp. Years - ?'. The fields like 'Time per week','Email', 'Location' etc. remain common for all.

Hence, if we have one single User form with all the fields (superset), can we provide Sub-Forms or Views of that as sign-up forms depending on his desired volunteer area selected? Is this commonly done is Drupal?

Regards,

Kiran

[Chris]

Yes; my thought was that each OG, etc would have an owner/
administrator, that could scan the group, and decide to add them to
roles they also administered. Perhaps would-be volunteers create an
"offer" CCK item, with booleans if they would perform one or more of
the tasks (imagery change detection, video transcriptions, etc) and
then role owners can scan the offers, contact them, and then mark the
offers as processed or something..?

Chris

[Kiran Vaka]

Would also like to mention that the volunteer signup / registration form needs to be multi-lingual - in this case, English and French/Creole. The multi-language component needs to be part of our architecture from the beginning, and adding a new language in the future should be a simple task.

http://drupal.org/handbook/modules/locale

We had already converted part of the workflow UI to French during the Crisiscamp on 16th; attached is the file.

Also we need to prioritize the implementation of the common library functions shown in the strawman architecture, and decide which one's need immediate attention.

Regards,

Kiran