How To Create Policy on a Wiki

Over the weekend, I learned about LexPop, a new wiki-based site that invites participants to collaboratively craft public policy on any issue (see their current project: Policy Drive: MA Net Neutrality). From the about page (emphasis theirs):

Just as pamphlets were once the most efficient and effective means for distributing ideas, so too was this type of democracy the best solution at one point. But that moment is long since passed. A legitimate twenty-first century democracy will invite the public into meaningful collaboration.

And that’s the theory behind LexPop. The idea is that we (the People) can do a better job. The idea is that by introducing more voices, the policies that win out won’t be limited to the best-funded.

The project is ambitious, but something similar is already working in Brazil. The Federal Government is experimenting with collaboration through ExpertNet and Peer-to-Patent. Yet neither of these projects opens the gates to policy making by the people. LexPop is a start that, and while imperfect, it will help bring public participation into public policy.

A recent blog post provides more background:

The notion that participants can create real policy is bold. But it’s no more so than the idea that users (in their spare time) could collaboratively create the world’s best encyclopedia, improve the US Patent and Trademark Office, and, well, develop Linux and Firefox.

I’m aware of a few attempts at wiki-based policy making, but as far as I can tell the results have been rather mixed. A big fan and regular user of wikis myself, I certainly find the idea intriguing. However, the analogies (Wikipedia, Peer-to-Patent or the development of certain open source software) don’t really apply to the policy making process. For example:

• Wikipedia and Peer-to-Patent both deal with facts, whereas policy always involves a combination of positive and normative issues. The process of collaboratively collecting facts is quite different from a policy argument or deliberation, and it has to be managed differently.
• Wikipedia as well as most open source projects are open-ended, whereas policy creation is very much a time-bound process. You can always make another edit on Wikipedia, but you need to agree on a final version of a policy draft in order for it to move forward and through the legislative process.
• Wikipedia and Peer-to-Patent both benefit from large numbers of small, independent edits and contributions. However, editing a policy document without at least some level of understanding of the whole usually does more harm than good.

Here is the comment I left back in December, when someone on ExpertNet raised questions about the wiki process (mainly what kind of edits are appropriate where, when, by whom etc.):

In order to engage a large group of participants in the review or co-creation of a policy document such as this one, I suggest the following iterative process:

1. Participants discuss draft language in the discussion forums (for example, they can ask clarifying questions, raise issues or suggest improved language)
2. A small team of dedicated editors (usually on the convener side, but might include a few volunteer participants) revises draft based on participants’ input AND communicates which changes were made and why
3. Rinse, lather, repeat.

To date, this is the most efficient process I’ve seen to do this kind of co-creation of policy. Making meaningful edits to a complex policy document requires a lot of mental overhead, which most participants have neither the bandwidth nor subject matter expertise to commit to.

Trying to wordsmith while the document basics (general scope, outline, key points etc.) are still in flux is usually a terrible waste of energy for everyone involved.

And as I’ve argued before, quality participation doesn’t waste participants’ time.

A great example of the process outlined above was the highly collaborative effort across multiple organizations in 2009 to create the Core Principles for Public Engagement (see earlier posts here, here) led by NCDD and others (strictly speaking, the online collaboration relied on a discussion forum, not a wiki, but the same lessons apply).

A key success factor was the fact that the team of core editors was made up of highly qualified people who dedicated a lot of time working on the document. They were trusted members of the community, and they communicated very well with the larger group of several dozen participants. The total number of comments in the forum wasn’t particularly high, but still it took a handful of iterations to arrive at the final document.

The LexPop project will follow a simple three-phased process (research, deliberation, drafting). I’m not sure that’s enough structure to make it work, though it’s already a lot better than most other examples I’ve seen. Worth watching!