Category Archives: Dragon Trainer

How online conversations scale, and why this matters for public policies

I care about public policies, and try to contribute to their betterment. The road I am exploring is to take advantage of the social Internet to connect citizens among themselves and with government institutions to assess governance problems, design solutions and implement them – all in a decentralized fashion. I wrote a book to show it has been done, and to argue for it to be done more.

But it remains a tough sell. Many decision makers remain skeptical: why should online conversations converge onto evidence-based consensus? A few people who share a common work method can make an effective group, but a large number of very diverse and self-selected citizens – what I have been arguing for – is likely to collapse under the weight of trolling, controversy and sheer information overload. We have examples in which this did not happen: but we don’t have a theory to guide us in designing conversation environment which produce the desired results. Not good enough.

Some work I have been doing recently might provide a lead. As the director of Edgeryders, I marveled at the uncanny ability of that community to process complex problems – as I had done many times before in my years as a participant to online conversations. But this time I had access to the database, and – together with my colleagues at the Council of Europe and the Dragon Trainer project – I used it to reconstruct a full model of the Edgeryders conversation as a network. The network works like this:

users are modeled as nodes in the network
comments are modeled as edges in the network
an edge from Alice to Bob is created every time Alice comments a post or a comment by Bob
edges are weighted: if Alice writes 3 comments to Bob’s content an edge of weight 3 is created connecting Alice to Bob

I looked at the growth over time of the Edgeryders network as defined above, by taking nine snapshots at 30 days intervals, working backwards from July 17th 2012. For each snapshot I looked at four parameters:

number of connected components (“islands” in the network)
Louvain modularity of the network. This parameter identifies the network’s subcommunities and computes the difference between its subcommunities structure and what you would expect in a random network. Modularity can take any value between 0 and 1: higher values indicate a topology that is unlikely to emerge by chance, so they are the signature that some force is giving the network its actual shape; low values mean that the breakdown into subcommunities is weak, and could well have emerged by chance.
for modularity values indicating significance (above 0.4), the number of subcommunities in which the network is broken down by the Louvain algorithm

These indicators for Edgeryders agree that there is no partitioning in the network. All active members are connected in one giant component, whose modularity values stay consistently low (around 0.3-0.2) throughout the period analyzed. This is not surprising: my team at Edgeryders had clear instructions to engage all newcomers into the conversation, commenting their work (and therefore connecting them to the giant component). From a network perspective, the job of the team was exactly to connect every user to the rest of the community, and this means compressing modularity.

Next, I looked at the induced conversation, the network of comments that were not by nor directed towards members of the Edgeryders team. It includes conversations that the Council of Europe got “for free”, without involving paid staff – and in a sense the most diverse, and therefore the most interesting. To do this, I dropped from the network the nodes representing myself and the other team members and recomputed the four parameters above. Results:

there is a significant number of “active singletons”, active nodes that are only talking to the team members, but not to each other. This might indicate a user life cycle effect: when a new user becomes active, she is first engaged by a member of the paid team, who tries to facilitate her connection to the rest of the community (by making introductions etc. My team has specific instructions to do this). The percentage of active singletons decreases over time, from about 10% to less than 5%.
not counting active singletons, there are several components in the induced conversation network. A giant component emerges in February; from that moment on, the number of components is roughly constant.
the modularity of the induced conversation network (excluding singletons) is high throughout the observation period (over 0.5),
the modularity of the giant component is also high throughout the period (over 0.5). Interestingly, modularity grows in the November-April period, indicating self-organization of the giant component. In February it crosses the 0.4 significance threshold
the number of subcommunities in which the Louvain algorithm partitions the giant component also grows over time, from 3 in April to 11 in July

Subcommunities are color coded. Knowing Edgeryders and being part of its community (and having access to non-anonymized data), I can easily see that some of those subcommunities correspond to subjects of conversation. For example, the yellow group in the upper part of the graph is involved in a web of conversation about the Occupy movement and how to build and share a pool of common resources. Also, looking at the growth of the graph over time, subcommunities seem to grow sequentially more than simultaneaneously. This might be related to the management structure of Edgeryders: we launched campaigns (roughly one every four weeks) to explore broad issues that have to do with the transition of youth to adulthood. Examples of issues are employment/income generation and learning. So, an interpretation could be this: each campaign summoned users interested in the campaign’s issue. These users connected to each other in clusters of conversation, and some of them act as “bridges” across the different cluster, giving rise to a connected, yet highly modular structure. The video above has some nice visualizations of the network’s growth and of the most relevant metrics.

This looks very much like parallel computing (except this computer is made of humans), and could be the engine of scalability. As more people join, online conversation does not necessarily become unmanageable: it could self-organize into clusters of conversation, increasing its ability to process a certain issue from many angles at the same time. Also, this interpretation is consistent with the idea that such an outcome can be helped by appropriate community management techniques.

Ten years ago, Clay Shirky warned us that communities don’t scale. He was right, by his own definition of community – which is what in network terms is called a clique, a structure in which everybody is connected to everybody else. I would argue, however, his definition is not the most appropriate to online communities. Communities do scale, by self-organizing into structures of tight clusters only weakly connected to each other.

If we could generalize what happens in Egderyders, the implications for online policies would be significant. It would mean we can attack almost any problem by throwing an online community at it; and that we can effectively tune how smart our governance is by recruiting more citizens. appropriately connected, into it. We at the Dragon Trainer project are following this line of investigation and developing tools for data-powered online community management. If you care about this issue too, you are welcome to join us onto the Dragon Trainer Google Group; if you want to play with Edgeryders data, you can find them on our Github repository.

Coming soon: posts about conversation diversity and community sustainability based on the same data.

Dragon Trainer: enter Wikitalia

1 Reply

For over a year now I have been working on setting up a project to build a system for the improvement of online community management. I am convinced that this is critical to improve governance, because online communities are the easiest and cheapest way found yet to mobilize collective intelligence –and , especially in times of crisis, collective intelligence itself is the best card government institution can play to improve their abilities to manage large quantities of information and make good decisions. The project is provisionally called Dragon Trainer (I know, it’s nerdy, we will change it): it comes from the fact that getting an online community to perform a specific task (like exploring possible scenarios underpinning a public decision) is a bit like taming a large animal like a dragon: he is just too strong to boss around, so you need to design for the desired behavior to emerge. The main idea is to put at the disposal of public sector online community managers network analysis systems which are sophisticated yet simple to interpret, and that read directly the communities’ databases. This far, only large corporate platform like Facebook have these systems at their disposal: but that information is not shared with users, and then I don’t think these platforms are accountable enough to host public sector projects.

This endeavor was embedded into a broader research project, that I help crafting out under the aegis of a Spanish tech company, 24amp. Fortunately this project was selected for funding by the European Commission; unfortunately, 24amp had to withdraw from the consortium for administrative problems – despite the winning proposal mentions me by name as work package leader.

We are going to fix this. The board of Wikitalia (an Italian nonprofit for open government, inspired by Code for America) has decided to build Dragon Trainer as a new component of its smart governance suite. The project’s goals are fully consistent with those of Wikitalia: increasing the smarts, the openness and the collaborative nature of governance, especially local governance. I joined Wikitalia’s board to help just with that, so I will be following this project myself on behalf of the organization.

In the weeks to come I will explore possible paths for making this happen. My first goal is to build a (small) international partnership and raise the funding to develop both the code and the science underpinning it. What I would like is just a little money – the normal cut of European funded research, in the millions of euros, is way too large for this – but as free as possible from red tape and administrative duties: you give us money, we build the app. If you want to know more or get involved, you can watch the presentation video, join the Dragon Trainer Google Group or just write to me directly: alberto [at] cottica [dot] net.

Meet the dragon hatchling: herding emergent behavior in an online community (long)

Why is this important?

For some time now policy makers have been fascinated by entities like Wikipedia: non-organizations, loose communities of individuals with almost no money and no command structure that manage, despite this apparent lack of cohesion, to collaborate everyday in producing complex, coherent artifacts. Such phenomena are made even more tantalizing by the uncanny speed and efficiency with which they do what they do. Can we summon Wikipedia-like entities into existence, and order them to produce public goods? Can we steer them? Can we do public policy with them?

In order to do so, we will need to learn to craft policy into a new space, which – following Lane and others – we call the meso level. Such policies will not be targeted at individual behavioral change (micro policies); nor at the economy or the whole society (macro policies). They will be targeted at achieving certain patterns of interaction between a large group of people. Individual may and will move in and out of these patterns, just like individual water molecules move in and out of clouds; but this does not much affect the behavior of the cloud.

Operating at the meso level – running an online community of innovators, for example – entails managing a paradox. Structuring interaction among participants as a network of relationships, of which participants themselves are the nodes, can result in extremely effective and rewarding participation, because – under certain circumstances – each participant is exposed to information that is relevant to them, while not having to browse all the information the community knows. This results in a very high signal to noise ratio from the point of view of the participants; they often report experiences of greatly enhanced serendipity, as they seem to stumble into useful information that they did not know they were looking for and was sent their way by other participants.

This extraordinary efficiency cannot be planned a priori by community managers, who – after all – do not and cannot know what each individual participant knows and what she wants to know. The desirable properties of networks as information sharing tools arise from the link structure being emergent from the community’s endogenous social dynamics. The paradox stems from the fact that endogenous social dynamics can and often do steer online communities away from its goals and onto idle chitchat or “hanging out”, that seems to be the default attractor for large online networks. So, managers of communities of innovators need to let endogenous dynamics create a link structure to transport information efficiently across the network while ensuring that the community does not lose its focus on helping members to do what they participate in it to do.

Building Dragon Trainer: a case study

With this in mind, I joined forces with emergence theorists, network scientists and developers to build the prototype of Dragon Trainer, an online community management augmentation tool. It models an online community as a network of relationships, and uses network analysis as its main tool for drawing inferences about what goes on in the community. Generally speaking community managers build knowledge of their communities by spending a lot of time participating rather than using formal analysis; and they act on the basis of that knowledge by resorting to a repertoire of steering techniques learned by trial and error. The error component in trial-and-error is usually fairly large, because by construction there is no top-down control in online communities; the community manager can only attempt to direct emergent social dynamics towards the result that she sees as desirable. Control over the software does give her top-down control in the trivial case of prohibition: by disabling access, or comments, she can always dampen activity directly. What she cannot do without directing emergence is enhancing activity – which is what online communities of innovators are for.

DT aims at augmenting this approach in two ways. Firstly, it allows the community manager to enrich the “local” knowledge she acquires by simply spending time interacting with the community. Such knowledge is extremely rich and fairly accurate for small communities, but it does not scale well as the network grows. Network analysis, on the other hand, scales well: computing network metrics on large networks is conceptually not harder than doing it on small ones, though it can get computationally more intensive. In an ideal situation, a community manager might start to use DT when her network is still small and she has a good informal understanding of what goes on therein simply by participating in it; she could then build a repertoire of recipes. We define recipes as formalisms that map from changes in the mathematical characteristics of the network to social phenomena in the community represented by that network. Recipes of this kind enhance the community manager’s diagnostic abilities, and take the form:

Network metric A is a signature of social phenomenon B.

As she tries out different management techniques to yield her desired results, she would then proceed to build more recipes, this time mapping from management techniques to their outcomes – the latter being also be measured in terms of changes in the metrics of the network representing the community. Recipes of this kind enhance the community manager’s policy making, and take the form:

To get to social outcome C, try doing D. Success or failure would show up in network metric E.

She then might be able to lean on repertoires of recipes of both kinds to run the network as it gets larger, because the software does not lose its ability to monitor those changes. These repertoires of correspondences are going to be built by integrating inputs from two different sources. The first one is theoretical: the systemic theory of emergence in the social world that some of my colleagues are engaged in developing. The second one is practical: the firsthand experience of community managers, myself included. Once built, the two repertoires would make up DT’s knowledge base, its computational intelligence core.

What follows is an account of a concrete case in which network science helped formulate a policy goal, the completion of which could then be monitored through, again, network analysis. It is only a small example, but we believe directed emergence is at work in it. And if emergence can really be directed then yes, in principle public policies can happen in the mesolevel and become closer to Wikipedia.

Context

In March 2009 I was the director of an online community called Kublai, a project of the Italian Ministry of Economic Development. People use Kublai to develop business plans for creative industries projects or companies. At the time it was about 10 months old; we had about 600 registered members working on 80 projects. I directed a small team that did its best to encourage people to try and think out new things, and to help each other to do so. Most creatives find it hard to achieve critical distance from their pet ideas, and an external, disenchanted eye might help them become aware of weaknesses or untapped sources of strength. Even simple questions like “why do we need your project?” or “how do I know this is better than the competition?” can help.

These conversations happen online, in the context of a small, dedicated social network that used the Ning software-as-service platform. We customized Ning’s translation to change the names of the “groups” functionality into “projects”: the object in the database was still the same, but rhetorically we were encouraging people to come together to collaborate to a project’s business plan. Ning groups lent themselves well to the task, because each sports (1) a project wall for comments; (2) a forum for threaded discussion; (3) group-wide broadcast message functionalities at the disposal of the group creator. In March 2009 the largets projects/groups in Kublai had about 60/70 members.

Ruggero Rossi, like me, is passionate about self-organizing behavior in the social world. When he proposed to do his thesis by running a network analysis of the Kublai social graph, I supported him in every way I could. The thesis was supervised by David Lane, a complexity economist I admire, which was an added bonus.

March 2009: diagnosis

The first problem was to specify our network. We decided nodes would correspond to people: each user is a node. The links could be several things, since there are several types of relationships between members of a Ning social network: relationships might be created by adding someone as a friend, leaving a comment on her wall, sending her a message, joining the same group/project etcetera. We decided to focus on collaboration in writing business plans, which is Kublai’s core business; we also decided that, in the context of Kublai, only writing in the context of a group/project counts as collaboration.

So we defined the link as follows: Alice is connected to Bob if they both have posted a comment on the same project. This is a somewhat bold assumption, because positing some kind of communication between the two implies that everybody who ever posted anything within a project reads absolutely everything that is posted in that project. I thought that was reasonable in the context of Kublai, also given the short time frame in which the comments had been piling up. This implies a bidirectional relationship: in network parlance, the graph is called undirected, and its links are called edges. The edges are weighted: the edge connecting Alice to Bob has an intensity, or weight, equal to the number of comments posted by Alice on the project times the number of comments posted by Bob on the same project. If they collaborate on more than one project, we simply add the weight of the link created across all projects on which they are both posting comments.

Eventually Ruggero crunched the data and showed me his results, that boil down to this:

all active (posting) members of Kublai were connected in a giant component: there was no “island”.
a kernel of people who were highly connected to each other acted as Kublai’s hub, connecting each participant to everybody else in the network. All of the paid team members were part of this kernel: no surprise here. More surprisingly, many non-team members were also part of the kernel. So many, in fact, that if you removed all of the team members from the graph it would still not break down; everybody would still be connected to everybody else.

Summer-fall 2009: policy

This was an epiphany for me. I discussed these results with the team, and our interpretation was this: a core of dedicated community members was forming that was buying into Kublai’s peering ethics. They took time off developing their own projects to help others with theirs. This was a very good thing, in two ways.

it implied efficiency. With more people participating in more than one project, Kublai could do a better job of transporting information from one project to another, and that is the whole point of the exercise. Alice is stuck with her project on some issue, and it turns out that Charlie, somewhere else in the network, has run into the same problem before. Alice does not know this, but she does collaborate with Bob, and Bob is a collaborator on Charlie’s project. So Bob can point Alice to what Charlie already did: Alice needs not walk Charlie’s learning curve all over again.
it implied resilience. If enough people do this, we thought, maybe the Ministry can turn Kublai over to the community, which will keep running it at little or no cost to the taxpayer. This would have created a public good out of thin air. Not bad!

So, we decided to encourage this self-organizing feature. How to do it? A way to go about it was to encourage especially people who were developing projects (progettisti) to interact more. What could bring them together? Purely social stuff like football or celebrities discussion groups were not even considered: they would mar the informal, yet hardworking atmosphere of Kublai. According to my readings on the early days of online communities, something that any community loves to do is discussing itself. So, we thought we would turn over some of the control over the rules of Kublai to the community, and we would put a significant effort in it. We created a special group in Kublai, the only one that was not a project at that point, and called it “Club dei Progettisti”. Joining was unrestricted; also, we actively invited everybody in the kernel and everybody who had started a project up to that point. We did things like coordinate to welcome newcomers and discuss the renovation of the Second Life island we used for synchronous meetings. The atmosphere was that of the inner circle, the “tribe elders” of our community. This went on from about May to the end of 2009.

December 2009: policy assessment

Was the policy working? It was hard to say. The Club dei Progettisti grew to be by far the largest and most active in Kublai, but that does not mean that people interacting more in that context would then go on to collaborate on business plans in the context of individual projects, that was our real goal. It did feel like we had a vibrant community going – but not all the time. And then vibrant with respect to what? And how does vibrancy translate into effectiveness? We spent a lot of time online, and sailed by instinct. Instinct checked green, but let’s face it – after one thousand users and 150 projects it was hard not to lose the overview.

With another round of network analysis I would have been able to have a stab at policy assessment. In network terms, I wanted the kernel to be bigger: more people not from the Kublai team, collaborating across more projects, would facilitate the information flow across projects and improve efficiency. But Ruggero had finished his thesis, and the administrative structure running Kublai was at this point so rigid that contracting him was next to impossible.

Only recently, two years later, did I get the chance to crunch an export of the Kublai database. We at the Dragon Trainer group extracted a snapshot of Kublai at March 23rd 2009 (the same day Ruggero scraped it for his thesis) and one at December 31st 2009.

Kublai community graph 2009

In these two images the nodes, representing members of the Kublai community, have been color coded according to a measure called betweenness centrality, indicating how often the node is in the shortest paths connecting other nodes (it is often interpreted as an indicator of brokerage efficacy). Yellow nodes are the least central and blue nodes the most central, with orange ones in an intermediate position; nodes representing the Kublai team employees (typically very central) have been dropped from the graph altogether. In March 2009, a handful of community members, less than ten, collaborated on several projects on a regular basis – and, as a result, did most of the brokerage of information across the network. In December, however, their number had about doubled, despite the fact that attaining orange or blue “status” required a lot more work (the most central node in the March network has betweenness centrality 1791, the one in the December network 7740). At the end of the year, Kublai’s kernel was both larger and more connected than it had been in March. This growth is an emergent social dynamics: there is no top-down control in these graphs, anybody I could tell “go form a link with X” has been dropped from the dataset. But this emergence is somehow directed: we wanted to get to a social arrangement whose graph looks like this.

You can see how powerful this thing is. We can already say something just by looking at the graph; we have not even started to crunch the numbers, let alone do more sophisticated things. We could (and we will) compute and compare measures of network centralization; respecify the network in many different ways, allowing for link impermanence (if Alice and Bob are linked but don’t keep interacting, after a while the edge fades out), bipartite networks (what about a people-project graph?) directed graphs (links representing monodirectional help rather than bidirectional collaboration: if Alice posts on Bob’s project, she is helping him, but Bob might not reciprocate); and play with the data in as many ways as we can think of.

We keep working on this, and we will continue to share our results and our thoughts. If you want to be a part of this effort, you can, and are absolutely welcome. Everything we do (the data, the code, the papers, even the mailing list) is open source and reusable. Download what takes your fancy and let us know what you are doing. We are looking forward to learning from you.

Download the raw data (database dump, anonymized).
Download and improvethe code to export the data into file formats supported by the main network analysis software.
Download the exported data if you would like to jump right into the network analysis. .net files (Pajek projects) are importable also in Gephi and Tulip.
join our mailing list if you want to be involved in our discussion. Everyone welcome, no technical background is required. We are online community managers mathematicians, coders, public policy practictioners, committed to being interdisciplinary and therefore to going out of our way to make anyone feel welcome.