Implementation details for Canvassing and GOTV ...

We've received a small amount of funding to help start our work on Canvassing and GOTV. We are still looking for sponsors, if this work is important to you, please consider supporting the project by making a contribution. We are also coordinating with Xavier on his work with CiviPetition. We revised the implementation details a few days ago to allow the canvassing module to use more of the civicrm core objects rather than creating new objects/tables. We also generalized the structure to enable CiviPetition to share the same objects. The key idea was to treat canvassing and GOTV as Survey(s). A petition should also be treated as a survey and hence reuse the same code structure. Fields specific to Canvassing or Petition can be added via CiviCRM's custom group mechanism. The phase will introduce a Campaign object in CiviCRM. This will allow users to relate and track things like mailings, donations event registrations, membership campaigns, pledges etc as one unified piece in future versions. Campaigns will be hierarchical (i.e. ability to have sub-campaigns). A campaign will also have civicrm contact groups associated with it (either included or excluded) and can include / exclude other campaigns. Another object is the Survey object. A survey is associated with a campaign and has a type (Canvass, PhoneList, WalkList, GOTV etc). A survey is also associated with an activity type. This activity type can be of type, "Activity Type - Survey" or can be a more specific activity type based on the survey type (i.e. "Activity Type - Canvass") or can be associated with that specific survey instance. This allows us to extend activities very specifically based on the survey activity type. Thus we can have a standard generic PhoneBanking questionnaire or we can opt to have a very specific questionnaire for a specific PhoneBanking survey. All the questions that are related to a survey are stored in a custom group that extends activity. We extend a custom group on one or more activity types and thus can make it general to all surveys, specific to a group of surveys, or very specific to one survey. We store the "interaction" data (who/what/when/details/location/phone) in the activity object. Some survey specific data in a custom group extending survey (deployed as part of CiviEngage). This data includes snapshot of the surveyor/surveyee name and IP, the status of the survey (complete, pending, expired) and the result of the survey (committed, undecided, opposed). We also store an FK to the survey ID in this group. The answers to the questions are stored in the custom_value table for that custom group. The above scheme allows us to build and reuse a lot of the work that we have done with activities. This also allows us to optimize the activity framework and build more powerful reports around activities. For more specific details on the schema and structure please check the wiki page.

Comments

This sounds brilliant.

Is there a PayPal account that people can donate to in other than US dollars? The button provided on http://civicrm.org/donate is only for US$ donations to the Social Source Foundation (is that the best entity or CiviCRM LLC?).

Our clients are likely to benefit from the survey and campaign objects and we would like to support it and encourage them to do so directly.

We have also started quoting for projects on the basis that we contribute a specified financial amount to CiviCRM LLC, based on the size of the project, so it would be handy if there is an easy mechanism to send those contributions through in AU dollars preferably.

Andrew
Community Builders Australia

people can always donate directly here:

http://civicrm.org/donate

would be good to get civi to a state where we can accept multiple currencies on the fly easily :)

lobo