This new component is developed for and funded by eTownhall, a website allowing any organisation to create a virtual townhall. One of the function is a petition targeting the Members of the European Parliament (MEPs). Our aim is to create a generic CiviPetition usable for any type of petition, targeting other entities than the European Parliament.

How to create and use a petition

enable civicampaign
You need a profile for the informations you want to collect about the people that sign the petition (you need at least the email address, but can put only this one). The default "New Individual" profile works fine
You might want to ask other questions specific to the petition ("would you like to be recontacted","make your signature visible"...) ?.
Create custom fields on activities of type petition, and add them to a profile.
You can put as many as you want, and do a complete survey if you want

Other/Campaign/new petition
Give a name, choose a profile that contains an email
From the Petition Dashboard, click on more "sign". You have the address to use for the petition. It contains the fields you defined in the profile.

/civicrm/petition/sign?sid=1&reset=1

Introduction

The petition in a broader context

Signing a petition isn't a unique and separated event. Each contact is likely to have had other interactions with the organisation, either as a member, having received newsletters, having contributed financially. Even if the petition signature is the first time a contact is identified, this shouldn't be the only interaction, as the campaigner will want to send mass mailing to udpate the signatories, and more.

Besides, collecting signatures isn't the sole aim of a petition. How to present the signatures, how to allow the target(s) to see how massive the support is among the population is as important as 'simply' collecting signatures.

Moreover, we need to introduce a feedback loop: the target(s) should be able to answer, saying they heard your call or saying they won't act as your petition requests. Presenting this response to your supporters and the signatories is part of your campaign as well.

For eTownHall, the same civicrm installation will be shared between different campaigns and petitions, potentially organised by different organisations. Everyone that signed a petition is a contact. We enforce tight access rights (using ACL) so one campaign doesn't see the contacts of another campaign, but it allows us to simplify/relax the validation of a new signature on a campaign A if we know the contact has been previously approved on campaign B.

Proper dashboards

As a campaign organiser, it is crucial to have a proper overview of how the campaign works in real time. Is one partner website suddenly sending more, or less signatories? Is the conversion rate different for different channels? Are the newsletters a good way of getting more signatures? Are we able to engage the signatories to promote the petition among their friends?

A proper view allow the petition creators to react quickly enough is paramount to the success of the campaign.

Split testing

For every campaign, there are discussions about what is the right slogan, the proper phrasing, the ideal illustration... Endless discussions to make these choices, without proper empirical validation.

We want to add A/B testing, allowing to present different messages randomly to the visitors, to see if one work better than the other or test different layouts. This allows to measure properly what works best, and allows to really improve by choosing the best one based on a proper quantitative analysis, not only gut feelings of the loudest organiser.

Campaign vs. Petitions

For eTownHall -the petitions targeting the European parliament-, they are several distinct "groups" of contacts:

The signatories of the petition. This is a group that allows mailing lists & ACL.
The MEPs (targets of the campaign) that responded. They aren't necessary "supporters" of the campaign, as they can respond they won't support the call.
Possibly "sponsor/partners". These are often organisations that support the call and are "co-campaigners".

For each of these type of contacts, the activity of "joining" the group is different

The signature needs to verify automatically the "plausibility" of the signature. In practice, it means either sending an email asking to confirm the signature, or using a third party website (facebook connect or openid). Beside their contact details, more information is requested: eg. "do you want to be informed about the campaign" (opt in to receive more info).
Only existing contacts from a specific subtype can sign. Their contact details is already known, but they can add an extra messages "I think that campaign is good but...".
Only Organisations can sign, they need to be approved by the admins, and probably provides more information (eg a message of support, their logo, their url...)

On civicrm, every time a contact sign, support, respond, that's recorded as an activity. The activity has been extended so beside storing the information as associated to the contact, it also keep the relation with the "entity" (the petition). Each of these 3 petitions are stored as a petition(new type), that defines who can sign, and what are the fields to offer in the form (the profile). The 3 petitions are grouped together as belonging to the same campaign. This will be discussed at civicon, but the idea is to extend tags so they can be linked not only with contacts (and in 3.2 with activities and cases), but also with petitions and groups.

Content and Campaign

Activism module/Amnesty

A campaign is more than the petition. You need content pages to present the campaign, a blog of the organisers, a private space for the organisers to plan the campaign, donations requests, documents to download...

The general idea is that all this content is managed by drupal (and several custom modules), only the contacts & signatures are handled on civicrm.

There is a drupal module for campaigning, Amnesty is launching a campaign mid april and is going to contribute back the code. This need to be evaluated.

Michael Haggerty has a module (not sure what it does nor how, to be discussed at civicon).

http://drupalcode.org/viewvc/drupal/contributions/sandbox/techsoldaten/activism/

Integration with civicrm/drupal/OG

Each campaign is an Organic group. Each organic group has two civicrm groups:

admin (managers, those that manages the campaigns)
supporters/partners (the managers decide who they want. Only the partners organisations, active supporters...)

Every time a campaign is created these groups are created.

This already exists (civicrm/OG module).

? Custom dev: http://forum.civicrm.org/index.php/topic,12833.0.html

Petition

The petition is a new type in CiviCRM (already in the svn under the civicrm.petition branch). The properties of the petition:

Name
Detail (short intro)
profile top
profile bottom
type of contact to be created (to be added)
Needed existing sub-type (eg. Only existing contacts of a specific sub-type can sign)
thank you page (to be added)
thank you message (to be added)

Signatures

Each signature is an activity.

The activity table is modified to have two new fields: entity_id is the id of the petition, the entity_table is civicrm_petition. This allow to see the signatures among the other activities for each contact, and could allow to integrate some of the new functions of CiviPetition so they are applied to other type of activities than the signatures (eg a dashboard to see the registrations to an event ?).

Audit log

We need an audit log. Adding a new table with:

ip address
timestamp
location (geo lookup)
referer
id of the activity
id of the contact

The audit table could be used for other type of activities than the petition, eg to audit donations, registration to events, subscription to newsletters

The geo-lookup will be done by a batch process.

We will implement audit based on this log (eg. See if too many signatories comes from the same IP address.

Sign up form

The sign up form is multi-lingual. The default multi-lingual system provided by civicrm should work (ie. You have an extra parameter that defines the language, each label and field is translated into different languages).

Internationalization / Localization

We won't choose automatically the language based on the IP address (cf. Counter example Google, it doesn't work very well and you end up with nl page because you are based in Belgium), but let the user change the language (the default language can be defined).

Shall we use the language requested by the browser? A: We will leave the CiviCRM i18n / l10n functionality as is.

Signature validation

Each signature for a contact needs to be validated.

The default is to send an email with a link "click here to validate your signature" + display a page "you will receive an email shortly, check your spam folder if you don't, you need to validate your email". The link sent is the thank you page + a checksum token.
If the user signs with facebook connect,/openid the information is stored in the contact detail, and no confirmation email is sent
If the contact is already existing on the contact database, no need to confirm the email/contact.

The validation sets as permanent cookie (signed-Petition-ID:petitionid) to avoid multiple signatures from the same computer/user.

Thank you (engage more)

Once someone has signed, both the thank you email and thank you page are opportunities to engage further:

Tell your friends
Donate
Engage on another campaign
Sign the newsletter...
...

If the url contains a checksum, change the status of the activity (validated).

Target (MEPs)

Delivering the petition in a usable form has a huge impact on its success. Each target should be able to see how many signatures have been collected so far, and be able to respond.

Dashboards

Single unique url, without authentication (checksum token)

cf. example. (link)

News emailing

Every x days/week, the campaigners can send an update by email to the target(s).

Collecting responses

The target (eg. members of the parliament) can respond. This is a implemented as new petition, where the "signatories" needs to be contacts (of a specific sub-type, members of the parliament).

This petition (signature activity) is likely to have custom fields (eg. A message, an url). This is implemented with a profile containing custom fields (for the type of activity).

Campaigners

Dashboard

The dashboard should present both how the number of signatures evolves, how the different partners/channels bring signatories and how the trarget responds.

Cf. example.

Signatures overview

graph of number of confirmed signatures over the past month.
Number of unconfirmed signatures (sparkline)
Number of visitors (sparkline)
Conversion rate visitors/unconfirmed signatures
Conversion rate unconfirmed signatures/confirmed signatures
Number of MEPs that have answered/presented their opinion

Channels overview

Split by referrer/social network of number of unconfirmed signatures (piechart)
Split by referrer/social network of number of confirmed signatures
Split by referrer/social network conversion rate unconfirmed/confirmed
?? Information about what is statistically significant (0.05 ?)

"Partners" websites

Other organisations and websites can promote the campaign and ask their visitors to sign the petition. It needs to be possible to sign from within these external websites.

On v1, only the the signature form is going to be offered (using a widget). It might be extended on v2 to add custom dashboards per partner.

Widgets

A widget is the signature page, with a simplified explanation of the campaign (and link to the complete explanation on the campaign website).

This is the same form as the signature from within the website,, but without the menu and layout. ie. With ?snippet=1

Differences with Survey

These are the fields missing for a petition

2 profiles instead of one (no schema change)
3 messages (confirm, thank you, thank you Facebook). Right now, coded and same for every petition
A logo
An email (sender)

CiviPetition