As part of the EuroPetition project, I created for myself (and the others in the project) an idealised summary flow diagram of the process. It’s a four-stage model is used to illustrate the processes involved during the life of an individual petition , based on one I had done last year relating to the UK Parliament. Downloadable PDF available below.
The four stages a high-level overview of processes involved during the life of an individual petition, while showing the significant detailed processes. A variant form appeared in the paper I presented at EDEM09: it’s kind of a prettified update of the model I drew from the discussion the UK Parliament held on how its proposed petitioning system should work. The main changes have been to flesh out some of the details, highlighting optional elements, while being less specific about how the impact could take place.
The other change is to take into account how the Public-i system that is at the heart of EuroPetition works – I would like to thank the folks at Public-i and in the project generally for their input when putting this together.
Follow this link to download the much clearer PDF version. Contact me if you’re interested in getting the original Word document.
Having a flow diagram like this is useful in helping non-technical people understand the petitioning process, particularly with the coming requirement on English local authorities to have online petitioning I mentioned before.
Note the way this diagram brings out the importance of officers in supporting the petitioning process, with the petitioner only having a limited role within the system between submission and completion, particularly if they are not involved in moderating or facilitating a parallel online debate. An obvious omission is the role of the media in all this…
The diagram is also good for finding useful points at which data can be collected. Read below for my thoughts on what data can be collected and when from the actors and from the application itself.
I will blog in future on the common issues designers of e-petitioning systems face, and nature of the data that can be captured – but this will do for now.
Gathering data from the system
As with any ICT system the two major sources of information that are available for measuring the system are, whether for evaluation or for management:
- Participants (aka the actors in the system)
- The system – mainly the application database but hopefully supplemented by stats from the webserver.
Data from actors
From the flow diagram it is possible to identify the points at data can be gathered and from there to link the actors to the data requirements and identify the most appropriate instrument to use (probably online questionnaires supplemented by focus groups). The principles should apply for most e-petitioning systems.
|Actors||Stage at which data is gathered||Purpose|
|Petitioner||On submission of petition (1)||Demographics, motivations and expectations of petitioner, existing engagement with the political system|
|Participating Citizens||After signature submitted (2)||Demographics, existing engagement, perceptions of quality of debate, expectations
How was the petition found, actions after signing the petition
|After petition closed (or on six-monthly/annual cycles) (3)||Establish perceptions of usefulness of debates and lessons to learn (eg on moderation, anonymity)|
|Petitioner||On completion of petitions. (4)
Focus group of peers after tool has been operational for a suitable period
|Perceptions of the process, Whether expectations have been met|
|Assembly Officers, process facilitators||On six-monthly/annual cycles (5)||Understand context of processes|
|Elected representative (and their support staff)||On annual cycles plus event after elections (6)||Establish expectations and perceptions at the political level|
In case you haven’t worked it out, the numbers in (brackets) correspond to points on the diagram.
Data from the application
The system itself should of course generate as much data as possible – and be as transparent to the users and managers of the system as possible.
|Stage||Question(s)||Deduced from data from system|
|Submit draft Petition||How many are submitted||Numbers and outcomes|
|Refer to EU or region||Why? Ultimate outcome?||Numbers, time taken, reason|
|Petition denied (with reason)||Why?||Numbers, time taken, reason|
|Issue resolved||How and why?||Numbers, time taken, reason|
|Petition entered onto system||How many? How long? What subjects?||Numbers, time taken, subject|
|2.Input and Dialogue|
|Open and close||(Impact of) no of days open||Period petition was open|
|Collect signatures||Volumes||Number by week or day|
|Online debate||Volumes, subjects, quality||Volumes of activity|
|Withdraw or resolve and log reason||How many and why?||Date withdrawn or resolved|
|Comment from owner||Period taken|
These data requirements have obvious implications for database design.
Update: Fixed link to Public-i site – they chose this week to introduce major changes