Implementation of CiviCRM Voter Interview

The voter interview module allows a campaign administrator to define a target search universe within CiviCRM to serve to campaign volunteers for canvassing. It allows volunteers to enter reports of interview results in a distributed way with great freedom, but also provides full audit trail and management reporting.

The system is designed to run on a Drupal website that is supporting a single campaign effort which probably is not much greater in scope than 100,000 voters. The philosophy of the system is not to partition by precinct or other geographical unit, but to allow voters to recruit each other without regard to polling place. For get-out-the-vote purposes, of course, the campaign will marshall the results of canvassing in CiviCRM (or another system that can take the data from CiviCRM).

The system can be used to control a traditional phone bank or organized street walk operation. However, rather than controlling carefully the process of canvassing and data entry, a campaign using this system can choose to trust voters to recruit each other (with the encouragement and support of the campaign). If a user were to make systematic errors in data entry or deliberately vandalize data, technical support can simply delete the user entries from the voter interview system, flush the CiviCRM field that is maintained by the system and run the regular batch process -- it will reload all of the work of the other volunteers into CiviCRM. The system stores a record for each report of a voter interview, rather than updating a field about the voter. So, the reports from one user do not replace reports from another user.

The system allows a volunteer to choose a neighborhood (street, number range and side) that they wish to canvass The system will then serve the volunteer voters who are in that neighborhood and also within any target group (eg, likely voters) defined by the campaign The system reserves for the day those voters (up to a maximum of 100) for the volunteer So, the volunteer can print a list and walk or use the phone while sitting at a screen. The system allows the volunteer to assemble a series of streets for a planned walk by searching with the Add option.

The system only serves voters who have not already been reserved by another volunteer and who have not previously been contacted within a time frame set by the campaign based on the outcome of the previous contact.

To set up the system, the major steps are as follows:

1. CiviCRM must be installed and loaded with the voters that one intends to canvass. The voter data MUST include street_address data (as in 123R Main St, Unit 6) stored in the first line of the address field.
2. You must run the included file voter_interviewsql to load a blank voter interview and search audit trail file into your civicrm_database. This sql will also populate two helper tables for address parsing The easiest way to run the load is using the source command from the SQL console. The load should run in under one second.
3. Edit the file voter_interview/includes/file_access.php to insert the path to your civicrm.settings.php file (just below the banner).
4. The Drupal cron job must be configured to run at least nightly and must be run at least once before attempting to use the voter interview system. The cron job will pick up two tasks from this module: parsing of addresses into the their postal delivery elements and voter interview database maintenance Maintenance includes nightly expiration of reservations, purging of unreclaimed expired reservations (after 10 days), and pulling outcomes from the voter interview system into the CiviCRM field defined below.
5. A CiviCRM group must be defined by searching for the voters that one intends to canvass and making them members of a new group. The group cannot be a smart group or parent group You must create a plain group (which will cause individual records for each member to be stored in the table civicrm_group_contact) .
6. A custom data group of fields (not to be confused with the group of contacts) must be set up through /civicrm/admin/custom/group with a field reflecting possible canvassing outcomes.
7. For this field, you must set up multiple choice options Use a single character value and a descriptive label, for example, 1 for favorable, 2 for not sure, 3 for unfavorable.
8. Visit the admin/settings page and point the Voter Interview system at your contact target group and your outcome report field.
9. Visit admin/build/menu-customize/navigation and pull the menu items associated with the voter interview system into appropriate positions in the menu system. Note that if you do not see them on initial installation, you may need to refresh site cache via admin/settings/performance. Also, you will need to set up appropriate permissions in admin/user/permissions.
10. Visit the voter interview administration menu (voters/admin) to set recontact intervals -- these will control when voters who have been contacted once will be served to be recontacted (depending on the outcome of the first contact).
11. You may want to set up a page to introduce the system to your volunteers, explain your coding system and give them coaching as you see fit. The system allows you to configure a shorter message that will be visible directly on the main canvassing screen. The system is not designed to serve volunteers a full verbatim script, although for volunteers who are unsure, one could load a script in the message area.
12. Lastly, you may want to insert the lines in the file voter_interview.css into your drupal theme css This will make the wide tables in the statistical sections look tidier

You should be good to go and the screens should be self-explanatory, but feel free to contact willbrownsberger@gmailcom with any questions. You may also find assistance in the CiviCRM forum. It probably makes most sense to post comments directly there rather than in Drupal forum.

The attached file includes the Drupal module voter_interview and the include files that it requires and should be installed in your sites/all/modules directory on your site like any other Drupal add on. The file also includes the SQL (essential) and css (not essential) snippets mentioned above. Note -- you may need to run an ownership change on the files after you untar them. Tested first under Drupal 6.14 and Civicrm 3.01. Summarily retested under Drupal 6.15 and Civicrm 3.03.

Pending issues identified by users (possibly to be fixed or to be incorporated in documentation):

1. When setting up custom data groups to be used with Voter Interview, must apply to individuals not contacts
2. Values for interview outcomes must be alpha not numeric -- they are used as field names in the cross tab summaries and SQL won't take numeric as field names.

Note that the 1.01 file for voter interview does not include the household salutations maintenance routine (not essential for voter interview). You can download the household salutation routine here also. The household salutation routine is not internationalized and should be used with caution as it deletes and recreates all household relationships.