Why Github and Stack Overflow are the wrong tools for democracy

(Or: Why nerds should be excited about Reasonwell.)

I love Github and Stack Overflow – for code. Democracy needs tools for policy debate.

Many of us sense that Github and Stack Overflow have desirable attributes that are missing from the way we do democracy today.

Git and Github allow collaboration while respecting the sovereignty of each contributor. Each person has complete control over their own repo, with a full copy of everything. Anyone can fork a project, publish it, and collaborate with whoever they choose. Patches are merged on individual merit, rather than a person in authority entrusting chosen people with permissions to push changes. A full history graph is maintained for transparency and repeatability. Git’s decentralised model makes all this possible.

Stack Overflow allows a large number of people to contribute in a structured exchange of questions and answers. Unlike a meandering forum conversation, it encourages the best information to rise to the top. Users accumulate reputation by contributing good information on the topic area of a given Stack Exchange site.

We value these democratic attributes in the tools we use for collaboration in software development – so why can’t we have them in our policy debate?

We can.

We can take the core ideas which underpin Git, Github and Stack Overflow, and build them into a new tool specifically designed for structured debate. That tool is Reasonwell.

The key difference between software and policy is that the unit of a software project is a source code file hierarchy, while the unit of policy reasoning is an argument map. These are very different beasts.

An argument map is composed of claims and arguments. A claim is a sentence that states a proposition. An argument is a set of claims (the premises) that together argue for or against another claim (the contention). Those premise claims can also have arguments for or against them, resulting typically in a tree (but more correctly a directed graph) with chains of reasoning of arbitrary length. The graph can have cycles, for example where two claims appear in arguments against each other: “We should tax carbon emissions” vs “We should not tax carbon emissions.”

To help you internalise how argument maps work, I recommend Austhink’s tutorials and this blog post.

The dependencies between pieces of source code in a project are implicit, language-dependent, and complex. We need to maintain an entire project’s source code as a single coherent unit, with each snapshot contained as a commit. We have all kinds of testing tools for validating that a commit is indeed a coherent piece of code. A commit is ultimately what will be deployed, and we use versioning to manage incremental changes towards that.

The dependencies in an argument map are explicit, and fairly simple. An argument is only valid if you believe all its premises are true. An inconsistent state would be to rely on an argument while holding that one of its premises are false.

I’m not saying here that the dependencies within and between pieces of legislation are simple – far from it. But neither am I proposing that our policy debate should focus on collaborative development of legislative documents. I am proposing that our policy debate should focus on reasoning around claims in argument maps.

Your opinions on a debate need not be wrapped up and versioned together in a commit. To understand your incremental contribution to a debate, I don’t need to examine a patch that represents a coherent set of changes to your opinions on an arbitrary number of claims distributed across a debate. I only need to consider an argument you’ve proposed for or against a claim on which I might hold an opinion, to decide whether I want to accept your argument. When I consider the truth of the premises in your argument, I can consider anybody’s arguments directed at those premises, not just yours.

You own your opinions, but (aside from attribution) nobody owns claims or arguments. Your opinions can change over time – they are mutable. Claims and arguments can be treated as immutable objects.

Hopefully this is beginning to suggest to you an object model for argument maps. Time to detail the core of Reasonwell’s object model:

A claim is an immutable text string, identified by its SHA256 hash.

An argument is an immutable record, identified by its SHA256 hash. It contains:

  • The identifier of the claim that it bears upon (the contention)
  • A boolean indicating whether it argues for or against the contention
  • A list of identifiers of one or more claims that make up the premises of the argument

An opinion is a mutable record that associates a user with a positive or negative sentiment on a particular immutable object. An opinion on a claim indicates whether the user holds the claim to be true or false. An opinion on an argument indicates whether the user wants that argument to appear in their argument map or not. They accept the argument if it factors in their reasoning; they reject it if not. Accepting an argument doesn’t determine one’s opinion on its contention – it is valid to accept arguments both for and against a claim.

This is where the Stack Overflow part comes in: When you visit the page for a claim, you see a list of arguments for and a list of arguments against. Accepting an argument votes it up the list, and rejecting it votes it down. Reasonwell’s main goal is to collect the best arguments closest to the claims they bear upon. If someone has already made your point you can adopt it or propose an edit to refine it, rather than adding redundant arguments to the total volume of content.

Reasonwell’s object model covers some further types of immutable objects, to capture other aspects of the discourse in a debate. An assumption represents the idea that an argument is invalid because it relies on an unstated premise that might be false. A flaw represents the idea that an argument is invalid because it is in some way logically inconsistent. An edit represents the suggestion that some claim or argument is preferable to some other claim or argument. These objects are all identified using the same SHA256 hashing scheme as claims and arguments, and users can have mutable boolean opinions on any of them.

Reasonwell’s Git-inspired object model is also being extended to provide for citations of sources, and to provide for questions or issues to which claims are proposed as responses, very much like on Stack Overflow. Reasonwell’s representation of opinions may be extended in the future to provide for opinions that are held only in certain scenarios, rather that the current notion in which a claim is timelessly either true or false.

And now for the Github part: Reasonwell has a global view of each claim, displaying aggregated arguments from all users for and against. Reasonwell also publishes your opinions under your user profile, at reasonwell.com/username/... . When someone visits your opinion on a claim, they see whether you agree or disagree, and which arguments you accept or reject. When they visit your opinion on an argument, they see whether you accept or reject it, and if rejected, why. These pages are like how-to-vote cards, highlighting which checkboxes a user can select to adopt your opinions. You can link to a unique URL where anyone can see your opinions and your reasoning, and adopt your opinions or propose new arguments or edits.

There’s no need for pull requests on Reasonwell. When you propose an argument, it’s presented to all users who hold an opinion on the claim it argues for or against. When you propose an edit to an existing argument, that’s presented to all users who accept the original. When you propose that an argument relies on an incorrect assumption, that is presented to all users who accept the argument. And so on. These proposals are ranked and filtered by the crowd, just like answers proposed to a question on Stack Overflow.

Reasonwell’s inbox highlights proposed arguments, edits, flaws and assumptions on which you do not yet have an opinion. It also highlights inconsistencies within your argument map, such as an accepted argument in which you do not agree with all premises; and arguments you have rejected without yet giving a reason why. You stay abreast of the debate by entering opinions, accepting or rejecting new arguments and edits, dealing with criticisms of your accepted arguments and so on, until your inbox is empty. This, in combination with email notifications of new inbox items, drives the debate forward.

Like Git, Github and Stack Overflow, Reasonwell relies on no complicated heuristics or algorithms for text analysis. The rules of the game are direct and understandable. No participant in the debate need feel that they have been unfairly disadvantaged by an opaque actor in the system.

Structuring the debate around a collaborative argument map enables you to hold your own voice in a debate with a massive number of people. Every argument in the debate is aggregated into an organised structure, where the volume of information is determined by the number of distinct ideas, not by the number of people participating. It’s like debating with and against one person – a person who represents the opinions and reasoning of the rest of the world.

Reasonwell facilitates collaborative debate in a way that’s as inclusive and as flexible as collaborative software development on Github, structured and filtered like a question-and-answer exchange on Stack Overflow.

Reasonwell opened for public debate in Feb 2013. Follow @reasonwell for updates.