Personal tools

From 25C3 Public Wiki

- This is a sub-page of Liquid_Democracy_XP -

Contents 1 Application 1.1 Participants 1.2 The first process 1.3 Implementation 1.4 Architecture 1.4.1 Development system 1.4.2 Runtime system

[edit] Application

The purpose of the application is to give citizens a tool to formulate a wish, complaint or change on any process in an organized way, aimed at all monopolistic organizations of (european) states. "Monopolistic organizations" are all executive authorities of the public administration, including the classical policy, but also privately driven companies that hold some kind of exclusive product – like energy, water, medical service, transport, information etc.

The application does not try to offer a direct solution for all of these possible complaint (or "interaction") processes. It aims to provide a basic structure, that can be constantly expanded and optimized _without the need to code_. Instead, the process design will be done with a kind of visual programming, based on the concept of workflow – see BPMN.

[edit] Participants

Alas, the concept we follow here sees not only developer-user as participants. Instead there are four categories of project participants:

1. Citizens – (french citoyen), more precisely active citizens who are practically interested to take part in the processes. They are the end-users of the web application(s). A Citizen who starts a process is the process owner, with all consequences (versus Wikipedia).
   As we are addressing everyone, among them people new to web applications, we will present them simple, step-by-step interfaces. On the other hand, they do not have to handle media files (vs. MySpace or Youtube), and the processes are not time-critical (vs. Ebay). But, there are many of them :-)

• Public: As every human being is a citizen, citizen and public are the same group of people. But for our application we have to distinguish these roles, because not every part of a process that a citizens starts shall become public (at every moment). - Public is an even larger group than active citizens, but they will only read, and only (small, statistical) parts of the data we handle - so technically, we can cache the content for them, we need no session management etc.

1. Organizers – these are players like lawyers, journalists, speakers of civil society organizations etc. They play certain roles in the processes that are handled by our tool. We can expect them to have internet experience, but also more specific requests, like data export, calculations etc.
2. Process designers – people who are interested in the public affairs, possibly have expert knowledge about a certain branch and/or who are willing to spend attention towards processes they consider important. Other notions could be "activist", "quality manager", "consultant". They will be using our tool to negotiate and describe the processes (more precisely the 'process definitions'). Part of the process design is quality management (so a citizen can click a button "Comment this process definition"). These people need logical skills and structured thinking for their job, they will also be willing to communicate closely, and will accept more technically designed interfaces.
3. Programmers – this is the group we are about to organize here. It will produce the tool that the other participants use. They are all genius, by definition :-)

[edit] The first process

Given the broad scope of the project it may seem difficult to achieve some inspiring result within 3 days ("Erfolgserlebnis"). To facilitate this the workshop will concentrate on a first but also typical and important process.

Complaint process

Citizen reports his complaint: He appeared at the city bureau to register his relocation - but had to wait two hours, and was not treated friendly.

Exemplary process goes like this (assuming Citizen is already registered and logged in):

• Citizien chooses "Citizen Report" from the list of processes
• Help text explains the process and how to specify the reported event in three steps:
  1. Choose the branch from a (given) tree
     => results in a path like public-admin.local.registration
  2. Choose the breach (dt. Verstoß, fr. infraction) from a given tree
     => obstruction.time-lag and attitude.communication.unfriendly
  3. Choose the place where it happenend, just as close as asked by the given process to identify the department
     => Germany.Brandenburg.Eberswalde
• Private Text can be added on a fourth form - this information is needed to describe the event, but is never published, and stored encrypted on the server (via a passphrase by the process owner).
• Citizen clicks [activate] to trigger the process -> server generates a unique process id - like kl23568
• Citizen clicks [print letter] and prints the letter on his printer. Letter explains the basic idea of the process as well as the specific parts, based on the "branch" and "breach" properties. It also prints the private text (and says it's not public).
  The letter then asks the receiver (the adminstration bureau) to comment the complaint within a given time, and possibly file an complaint objection if they feel the complaint is not fair. A URL for the objection is given, and a hash code to commit it.
• Citizen signs the letter, puts it in an envelope with a stamp on it, and drops it in a postbox. He sets the status of the process to complaint shipped.
• Bureau gets the letter - but feels they're not responsible for timely or friendly service. Timeout passes and status is automatically set to "Valid".
• Statistics about "valid complaints" gets updated.

This is just an example - other processes might include other agents, like an ombudsman that negotiates content or status of a process, a journalist that asks all Citizens that reported a certain breach to open some of their private data for his article etc.

[edit] Implementation

For this 'process1' let us assume the work of the process designer is done. Now we could implement the process - by choosing some web application framework (like Ruby-on-Rails, Struts, Symfony etc) and write the application.

But if a process designer decides to change the process a bit (like "activation has to approved by another citizen"), he would have to call the developers again and ask for a coding change, test, approval etc. On the other hand, applications like this do not need that much flexibility in user interface, layout and structure.

As a consequence, this project uses the concept of workflow to model the processes.

There exist a number of workflow software tools but they do not solve our demand for a web app generator because they a) do not allow definition down to a field level and b) can not generate code.

[edit] Architecture

This software architecture distinguishes between development and runtime system.

[edit] Development system

This web application and tools are coded by the Programmers and used by the Process designers.

• Unix OS, like Linux Debian
• Apache web server 2.2.x
• Python - We work with: Python 2.5x (or 2.6x as soon as it*s supported by debian etc) and keep py3 compatability in mind.
  • wsgi (via debians mod_wsgi) as the connection layer between Apache and Python
• PostgreSQL 8.3.x is a very reliable and fast open source DB, 8.3 a XML support.
• We decided to go for Django as a web app framework instead

Please read Liquid_Democracy_XP#Preparation for hints on how to setup this environment.

[edit] Runtime system

This systems runs the code that was generated by the development system.

Runtime architecture:

• OS - any Linux, BSD, OS/X, even MS Windows
• Any web server that supports PHP, like Apache
• PHP 5, optionally with a runtime cache (Zend, eAccelerator).
• PostgreSQL 8.x or other SQL-Standard database. The runtime DB definitions, tables, functions etc. are also generated by the developement system.