Tag Archives: Edgeryders

Diversity is hard: how to enrich governance without losing coherence

Not everybody agrees that participatory processes lead to better public decision. They do enable decision makers to access the extraordinary wealth of diversity, information and first-hand experience embedded in the citizenry: this is their advantage, and it is an important one. But they also have two disadvantages.

such information is not organized. It is not simply a language problem: different people have different stories, and they just see things differently. If you ask someone what they think about pedestrianizing a street in the city center, for example, you are likely to get completely different answers according not just to that person’s position with respect to that street (does she live there? does she work there? does she own real estate in that street?), but also to her values, lifestyle, personality. A cycling enthusiast, or simply someone in good physical shape, will probably appreciate the advantages of pedestrianization, whereas a couch potato will be worried about restricted mobility. It just depends who you ask! Citizen participation (when the people involved are not very many, i.e. almost always) introduces an element of idiosyncracy in the decision making procedure – and this is a problem for public decision makers, that need to be accountable for whatever they do.
the discussion can become hard and unpleasant. Good debate requires debating skills, and not everybody has them. Public decision makers generally do: it is a part of their job description. Citizens, it’s hit and miss. Some tend to ramble, or are aggressive; others refer to values or information not shared by the whole community (“pedestrianizing is useless! Nostradamus is clear, a giant globe of fire will swallow the city next year!”). Some might try to apply rhetoric to delegitimize the process if they don’t get what they want (“why do you involve citizens, if you are not prepared to listen to them?”). Different discussion styles might lead to a polarizing, non-convergent outcomes just as well as different positions.

I am convinced that these problems can be overcome at a very low cost – I defend this thesis in Wikicrazia. There is a condition: that participating citizens are recruited from a community oriented towards open and rational discussion. Preferably from an online community. Here is why:

the members of these communities validate each other recursively, like Pagerank does with web pages. A person that makes wise, widely shared contribution to the conversation will quickly acquire reputation and authority. This is most visible in online communities, and takes the shape of accumulated comments, shares, likes, +1s or whatever the reputational currency is in each community. “Fishing” the highest-standing members from these open communities reduces the randomness of run-of-the-mill participatory processes.
communities train their members in constructive debate. In well-run communities trolls are isolated. Well-meaning, respectful people talk to each other, and compensate each wise contribution with the reputational currencies mentioned above. This, too, is easier online, where the underlying technology typically does not support seizing the microphone and holding on to it for lengthy speeches, or shouting, or interrupting. The most respected members of such communities tend to be people that is useful, even pleasurable to debate with – even when you do not agree with what they have to say.

Since I believe this is true, I am going to try something daring: invite some members of the Edgeryders community – giving them expert status – to discuss with professional researchers and European policy makers (if you want to take part, read the relevant info ). Will they really enrich the discussion without increasing its entropy?

Augmented ethnography: processing qualitative data from massive conversations

3 Replies

I am working on a project called Edgeryders, a massively collaborative exercise to reassess and redesign public policy towards youth. The idea is to get participants to share their experiences on policy-relevant topics, like how we make a living or how we participate in public life. As the project starts to pick up speed it does what crowdsourcing exercises do: it spews up a torrent of experiential data. In my book and elsewhere I have claimed that respectful conversations converge: a consensus is achieved, and we can just move on. I still think that’s true, and fairly obvious to the participants. The problem is how you convey it in a verifiable form to external observers – European governments and the European Commission in the case in question. Demanding that they go through even a small part of the raw data is simply not realistic. So what do we do?

My best guess is ethnography. Ethnographic methods are particularly well suited to this kind of investigation, because they are designed to embed the point of view of the people they study. For the same reason, I would argue that they are well suited to Internet ethics: we are not the lab rats, we are the lab itself, just as we are not the users, but the protagonists of our online meeting places. Modern ethnography employs software like Atlas.ti or its open source counterpart Weft QDA to annotate interview transcripts.

The advantage of social networks-based data collection methods like Edgeryders is twofold.

The data come already in written form. A major cost of ethnographic analysis, trascription of interviews (in 2006 they were talking about €100 per hour of recording), is therefore avoided.
Crucially, the data are really fragments of a conversation. Participants comment, contradict, praise each other. What might appear like different “interviews” (see this great example) are really linked to each other by a web of social ties, which are encoded into a database, and amenable to quantitative analysis.

In order to take advantage of these features, we are trying to develop a methodology that I have been calling augmented ethnography. It should work more or less like this:

first, organize the material by participant. In Edgeryders, this means gathering all of my mission reports (a sort of blog posts), my user profile, and my comments, and filing them under my online identity. This produces a sort of uber-interview of a participant (me), that extends over several topics. Repeat over all participants. Annotate this material with Weft or Atlas.it.
next, specify a network to represent the conversation. To a first approximation, I would start by considering the all participants are nodes of the same network. A link is created between participants Alice and Bob according to some interaction encoded in the database: the most intuitive one in Edgeryders is that Alice and Bob are connected if at least one of them has commented one of the other’s mission reports, or if both have commented a third participant’s. Edgeryders was intentionally designed with redundance in the relationship modes, so that different relationships could, in principle, evolve by exaptation to signify different things.
crunch the network data and look for structure that could help you. One of the first things I would try is to compute measures of network centrality for each individual. This would help solve the classic ethnographers’s problem: the researcher arrives in some remote island to investigate a community whose culture he does not yet understand. A person sits with her and provides a lot of information. How can the researcher use it? That depends whether she has been talking to a respected member of that community or to the village idiot – and the researcher may have no easy way of knowing that. Network analysis can help: in respectful, fact-oriented conversation, the village idiot will almost never enjoy a high degree of centrality.

Of course, this is only a rough sketch. I don’t doubt that many clever tricks can be devised that will work on ethnography-on-a-database. Now, the problem is finding researchers that can take full advantage of that: competent ethnoghraphers that can take in the results of network analysys too. Readers: do you know any? Is there anyone interested in picking up this conversation, and maybe give my team and myself a hand?

Zen and the art of website procurement: why bureaucrats should get their hands dirty with technology

16 Replies

In the past few years I worked for several public sector agencies. Much of my work consists of thinking up and delivering projects that happen mostly through Internet channels. This is a good time to take a step back and muse on what I learned. As always, the most valuable lessons come from mistakes made – so it’s a good thing I made a lot of them.

Software-as-service is a bad idea, though there are exceptions. My team and I made this mistake with Kublai, as we decided to deploy our platform on Ning. That allowed us to be up and running in half an hour, no small advantage; but we paid for it by sequestering our own database, procured and paid for by the Italian government, and handing it over to an American private company forever. A year later, Ning changed its CEO and business model: it moved its platform from the open source to the full copyright domain, disabled APIs and blocked migration tools. Just to do a network analysis, Ruggero Rossi had to write a web crawler – a bit like picking the lock to the door of our own home. It could have been worse: we were using a free service (that was before Ning rolled out pricing plans). If the company had simply shut down business, formatted the hard drives and walked away we could not have stopped them, since we were not in any contractual agreement. They would not even answer our emails. I am never going to even consider again rolling out a public sector project in which my agency does not have root access to the server hosting the database.
Using proprietary software is not a good idea either, again with some exceptions. It is expensive and it amounts to a open-ended commitment to your supplier. If a large software house develops custom software for you and then sells you the license, no one, except that same supplier, is ever going to be able to tweak that code. You risk finding yourself disempowered and stuck in a situation in which changing the color of the background or the font is expensive (as in billable hours expensive) and involves a lot of administrative friction. Furthermore, it is politically questionable: proprietary software is not reusable for free by other administrations, and that is not good – especially in a time of budget cuts and of (justified) skepticism vis-a-vis the effectiveness of administrations in spending taxpayer money.
That leaves free/open source software. I have been using WordPress in public sector projects since 2007; for the Edgeryders platform, more or less finished as of this week, my team ventured into Drupal. Working with open source software can be hard and frustrating. Features that are supposed to work simply installing a module or a plug-in turn out to have horrible bugs in practice; everything takes longer that you think; most of the work is not developing, but debugging. Meanwhile, the rest of the projects activities are stalled. It feels horrible. I think experience can mitigate the problem, but never really solve it. Free software is by definition organic and gritty: it works by hacks and duct tape as well as by elegant, rational solutions.

Despite all the problems, my experience of Drupal procurement is going to be positive in the end, as with WordPress before. The reason is this: these platforms allow, and even require, a hybrid figure of “power admin” to emerge, somebody who is less skilled than a developer but more so than a normal user. This happens because the admin interfaces of WordPress and Drupal are intuitive and very powerful; Drupal, especially, allows fine-grained control over your website. You can query the database, format the return of the query and send it to a page, a block or even an email message; you can tell the website to execute instructions of the kind IF [condition] THEN [action], not quite programming but on the border. Furthermore – and here I am thinking about my standing love affair with WordPress – when the admin interface is not enough, it is easy to find online resources and tutorials to get your hands into non-core parts of the code. I am technically incompetent, but still I have been able to teach myself to tweak the CSS in a blog’s style sheet, and even the PHP code for very simple tasks, like assigning different headers to different page or inserting a line of Javascript. That required a small-ish investment, to which the proliferation of “For Dummies” books in my library is testimony. This gives you an incredibly important freedom: that of developing in a quick-and-dirty fashion, launching, and then just keep tweaking as your project evolves. Trust me, you will feel the need from day one.

Here’s the trick: the hackerish power admin role is perfect for a public servant that needs to procure software. Getting to know the architecture of these platforms well and to take full advantage of their scope for customization does not make you developer, but it does mean being able to have a constructive conversation with your developers, get real on what can and can’t be done, how long it takes and how much it costs. Furthermore, a power admin can rethink her goals in terms of the software, and so come up with highly sophisticated terms of service for the procurement effort. For example, on Edgeryders we need to constantly reinvolve users in the conversation: this is done through email notifications and the recent activity feed. In Drupal, these functionalities are carried out by certain non-core modules. If the public servant knows this, she can procure not “a website that feels buzzing”, but “a website in which the activity stream module logs activities that are not logged out-of-the-box”, that is much clearer

When I got into motorcycle riding, I read the obligatory Zen and the Art of Motorcycle Maintenance. The lesson of that book is the following: the act of driving a motorbike is not really separable from that of doing its maintenance. “Romantic” bikers, who do not enjoy getting their hands dirty, don’t accept this, and delegate to professional mechanics even the simplest maintenance operation. But they pay the price of disempowerment, when their machines stop by the roadside and won’t get started again, and they don’t have a clue what’s wrong and how to fix it. This system failure can be disastrous in public policy: in the projects I manage technology typically accounts for less than 10% of the budget, yet if the technology is not there the entire project grinds to a halt.

Summing up, high quality procurement is impossible until you know what you are buying. In my experience the free/open source software community is up for sharing its knowledge; corporates producing proprietary software much less so. If, like me, you find yourself in the position of procuring a simple technological solution for the public sector, I recommend you turn to this community, arm yourself with patience and get your hands dirty with the technology the developers intend to use. Install and configure sandbox sites, add functionalities, tweak their look and feel. Spend time with hackers, show that you are eager to learn, an grill them with questions. Above all, don’t yield to the temptation of going “this is not my job, just make it work and send me the invoice”. It doesn’t work like that. This is very time consuming, but you will save that time, with interests, once you are in production. I know it’s not a perfect system, but it is still better than available alternatives. Truth be told, I think it would be really useful if somebody started a course of website procurement for public servants. Anybody out there is interested? I would certainly sign up.

Thanks Freddy Mascheretti, Ivan Vaghi, Paolo Mainardi and Claudio Beatrice for their patience and suggestions