Skip to content

Tools that facilitate and encourage informed, rational, democratic policy discussion

Notifications You must be signed in to change notification settings

luqui/democracy-tools

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

43 Commits
 
 
 
 
 
 

Repository files navigation

This is democracy-tools, a website for assisting democratic decisions. The mission statement is:

To develop tools that facilitate and encourage democratic, informed, rational discussion of policy.

So, I want to start with the debate app. It's like a forum, but it is set up specifically for a rational policy debate and exploration. We take from Sociocracy the idea of paramount objection. That is, on a Proposal, a user can enter a paramount objection: an aspect of the policy that is unacceptable (perhaps defined in the more precise sociocratic terms for some situations). These objections then form sub-discussions which move toward resolution. Thus the site guides the dicussion so that objections are not forgotten and so that the conversation stays focused.

It seems that it should almost be wiki-style, where anybody can edit, because much of discussion will probably not happen at the appropriate place in the forum: people will raise objections that are addressed elsewhere, etc. So we would like users to be able to reorganize the debate. However, as policy debates can get pretty intense, we don't want to allow censorship (or semi-censorship, in which reasonable objections are buried underneath piles of garbage). This will be a tension to resolve later. UNRESOLVED

Let's think about the organization of a policy debate. There are two situations:

  1. There is a problem that the community seeks a solution to.
  2. There is a proposal for a change that the community wants to evaluate.

In (1), the problem workflow, a user poses the the problem in a post and describes it in as much detail as he can. There may be discussion about what exactly the problem is, which may result in a modification of the description of the original problem statement.

Then users propose a solution, which, nested inside the original problem, use the proposal workflow.

In (2), the proposal workflow, there may be some clarifying discussion as before. Users then post objections to the proposal, which can be discussed and addressed. The objections use the problem workflow, in which people propose solutions, etc.

We see that the system has two interacting parts, alternating with each nesting: problem, proposal.

There are two related decisions to make about problems and proposals. They are:

  1. How does a community select a proposal to use out of the proposed?
  2. How does a community resolve an objection?

These are in fact the same problem: to resolve an objection is to select a solution for it. The selected solution may sometimes be "this is a proposal-killer", so we have to allow an objection to ripple its way up to the main line of discussion.

Actually, maybe "this is a proposal-killer" is not a resolution. In those cases, we leave the objection unresolved, signaling that this is an open problem and that a solution has yet to be found (but not closing off the imagination as "there is no solution").

A proposal can only be accepted when there are no remaining objections.

But suppose there were three proposals, all of which have no objections. We need further criteria for selecting a proposal.

Reddit-style voting perhaps. People upvote proposals that they like, or raise objections to proposals that they don't (thus requiring expression of why they don't like it). When the highest-voted proposal (beyond a threshold) has no objections, it is accepted. This is subtly different from selecting the highest-voted with no objections, which would mean that if you raised an objection to a popular proposal, it may automatically select a less popular one rather than giving the community a chance to resolve the objection. So a winning proposal must not only be objection-free, but gain the majority support of the participants.

Ok, here's a voting mechanism. Each person has "consent tokens". They aren't finite in number, but they do have some rules to them. If you have a consent token on a proposal, that means that that proposal is acceptable to you. If you have a token on an objection, that means that the objection makes the proposal to which it is objecting unacceptable to you. Thus, you can't have a token on a proposal and on one of its objections at the same time; similarly you can't have a token on an objection and one of its solutions at the same time. The number of people with tokens on a proposal or objection determines its score, thus its sort order.

Proposals and objections are editable (history viewable), comments are not. The comments record the discussion, whereas the proposals / objections represent the latest state of knowledge.

About

Tools that facilitate and encourage informed, rational, democratic policy discussion

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published