Campaigning Camp 2010 Report

Two weeks ago Michael McAndrew, Xavier Dutoit and me (Piotr Szotkowski) had the pleasure to attend Campaigning Camp 2010, hosted by FairSay in Oxford, UK. Campaigning Camp was a two track event, with concurrent CiviCRM and Plone development sprints interspersed with general campaigning advice from FairSay’s Duane Raymond. After an initial round of presentations and general discussion the attendees split into three main teams, focussing on discussing and developing CiviCRM petitioning module, CiviCRM canvassing module and Python library for accessing CiviCRM (for future use as a Plone/CiviCRM integration point). The CiviPetition group, coordinated by Xavier, started hacking on a module for creating online petitions and collecting ‘signatures’ – people who back the given petition – and registering them in CiviCRM. The initial code created during the sprint is in the trunk.civipetition branch in our repository. The CiviCanvass group, coordinated by Michael, discussed and started hacking on module for canvassing a subset of CiviCRM contacts – the original specs for which can be found on the wiki. The general idea behind this module is that a CiviCRM operator can select a subset of contacts and be exposed to an interface with a set of canvassing questions for every contact; this list can be then used to collect data online (e.g, by calling the contacts on the phone) or used as a walk list for face-to-face campaigning. The initial code created during the sprint is in the (somewhat confusingly named) trunk.civicampaign branch in our repository. As per Michael’s report, this group also looked at work done by Mike Haggerty at Trellon on Drupal’s Activism module, and coordinated with Mike to integrate this module with CiviCRM. Both the petition and canvassing groups ended up with the unobvious, but very interesting conclusions that it’s actually quite beneficial to model both the petitions and the canvassing as activities on contacts (rather than, say, custom data group). Such an approach has quite a few benefits: for example, the CiviCRM operator doing the canvassing work is often a volunteer with potentially limited CiviCRM proficiency, and reverting/discarding his work is trivial when all of the canvassing is done as activities between the canvassed contacts and the operator’s contact; at the same time, the created activities are easily searchable and if needed the collected data (once approved) can be relatively easily moved to relevant contact custom groups. The above thinking sparked a conversation about how we should more often consider the existing CiviCRM ‘objects’ (such as relationships or activities) when designing new functionality; this discussion will be continued during the upcoming CiviCon. Xavier’s and Michael’s first-hand experiences on creating CiviCRM modules was also quite beneficial, and should result in better documentation of the process. Another topic discussed at the camp was a general CiviCampaign module, which would be an umbrella solution for grouping all events, mailings, contribution pages, petitions, canvassings, etc. that are related to a given campaign. This will be discussed further at CiviCon, but the tentative idea is to, once again, base it on existing CiviCRM objects: this should be possible to implement by extending the tag system to cover all of the relevant elements. The Plone group, coordinated by Mike Rhodes from Netsight (with me sharing the time between them and CiviCanvass), discussed on how to best access CiviCRM from another language – in this case Python – for integration with non-PHP tools in general and Plone in particular. Thanks to previous work by Xavier, the CiviCRM public API can be accessed via the CiviCRM REST interface (which, being based on HTTP, is programming-language-angostic). The initial discussion about how to best integrate CiviCRM with Plone quickly turned to developing a general Python library for accessing CiviCRM, and subsequently turned to the question whether it should follow the CiviCRM API conventions (simpler to implement, but less natural to use by Pythonistas) or wrap them in a more Python-like way (more work, but much nicer to use). This discussion ended with the general conclusion that it’s not an either-or choice, and in fact a small, ‘thin’ Python wrapper can be a great basis for a future ‘rich’ library. The tangible result of the above discussion is the PyCiviCRM library developed by Mike; its development also sparked many chats on which way should we extend the CiviCRM public API (such as being able to request a list of custom data fields that extend a given contact type) and possible future integration points – like the ability to use CiviCRM as an authorisation service (‘the fnord user in our system is mapped to the Fuy Gawkes contact in a remote CiviCRM install – let’s check whether that contact has certain features there before we let the user perform an action here’) or for more sophisticated way to collect CiviCRM data than what is currently available through copy-pasting profiles’ HTML code. On the non-strictly-coding front, Duane started work on a matrix plotting the capabilities of campaigning tools and Eugene Flynn from 54 Degrees worked on ‘user stories’ for activism users, including simple visual designs. If you’re interested in further Campaigning Camp developments, do feel free to join the Campaigning Camp mailing list!