You can have a look at one library on my computer (during the day->0800 till 0030 paris time, it's off at night because the computer is just too noisy for my sleep).
I think Sunir has figured out most of it.
VVV is a collaborative writing tool based on the simplest democratic principles [I could think of]. The goal is to allow a community to produce documents through three simple actions: propose/choose/delegate.
The documents are assembled in a library. They are constituted of a tree of elements, like book, chapter, article, preference, action, message, link.
Every person in the group of users can propose elements. Each one can state their agreement/disagreement with an element through a yes/no vote. Any one can delegate their vote on an element and its sub-elements to someone else.
The delegations are transitive and can be overriden on a per element basis with sub-delegations or choices. That feature requires resolving some pretty complex graph problems, but their use is very straightforward as far as the user is concerned. Below each element are displayed the delegates, in the same combo box used to cast a delegation, are displayed the name and % of controlled voices for associated delegates.
Choices (yes/no votes) and delegations can be changed at any time. The group can define a period (through a preference element, not yet implemented) after which choices and delegations can be rendered inactive.
The texts of a library can be viewed using a filter, "à la slashdot". That means you only view the elements which have an agreement/disagreement level superior to a % you choose.
The possibility given to everyone to propose and choose makes VVV a direct democracy. The delegations make it a participative democracy, and allow one to rely on others to handle all evolutions of the texts.
Setting the amount of time before choices/delegations are inactivated to a small value (like 2 days) can produce a newspaper where articles move up and down in their level of agreement, and so you will only view articles which are currently considered interesting by the community.
The message element allow the library to also be a forum where parent elements are discussed.
A difficulty arises when considering the % of participation. Because the level of agreement/disagreement is a simple (agree-disagree)/nb_active_persons*100, if many persons have just made one action (which make that person active) and nothing else in the whole library, then the level values will accordingly be smaller and appear less interesting.
Note: to those viewing this system as a replacement to a parliament, they are right, it is such an attempt. But there is one large difference to keep in mind, there are no dates set right in the system. That's due to the fact that everybody can change their mind and modify their choices/delegations. Moreover, the 50% majority mark is not very important here either, because the level of acceptance is a substraction between agree and disagree; thus it gives importance to the "volume" of participation, the "yes" and the "no", and not just one of those values...
Thanks for letting me raving about my baby :-)
I left my former job to work on VVV, and four months later there is a working first draft, although still not complete. Now, well, I needed money, so I'm working at alcove (free software consulting society in France), but I still want to make VeniVidiVoti a tool which could bring politics to the virtual world. In fact, I strongly believe that the principles described here could definitely help not just politics, but any activity where there are more than just a couple of persons involved, like writing a novel, a newspaper, a poem, a constitution.
You tell me if I'm stupid, and should just get on with the other projects I have in mind...
(feel free to correct anything my French head writes.)
You want "suffragavi" which does mean "I voted".
It's an English pun, not a Latin pun.
[ed: The following is based on a conversation I had in e-mail with EmmanuelCharpentier, but it's not necessarily accurate. --ss]
VeniVidiVoti is a CollaborativeHypermedium whose goal is to produce documents. The documents are structured in the BookMetaphor, but with each element in the "tree" (or hierarchy) as an individual editable node. This is much like threaded newsgroups, or FaqOMatic?.
Everything in the system is done through voting. To create a node, you make a motion that members must vote to pass. To make a new revision of a node, you submit new copy that members must vote to accept.
You can either vote directly yourself, or give your franchise to someone else who can vote on your behalf. That individual can turn around and hand your franchise to another individual. In other words, your francise is a commodity that can be given away. This is similar to the Wiki:StoneSociety.
Motions and delegations of franchises are time-limited ala DynamicValue.
There doesn't seem to be a public, working version of this system to use. Moreover, the user interface really breaks my LynxFriendly head. So, while the idea sounds interesting, the execution could use tweaking. Then again, don't think that microvoting is a good idea, but maybe the delegations are the answer ala RatingGroups. -- SunirShah
In a few words, it's a library holding the texts that are democratically written by a group. It attempts to be the perfect mix of participative and representative democracy. And as far as I'm concerned, the principles behind it would definitely give a working political system, although the implementation can be discussed.
The principles: everyone can propose, choose or delegate choices, concerning the elements of a text. -- EmmanuelCharpentier
Delegation is normatively a directed acyclic graph. In the event that a cycle is created, all franchises on that cycle abstain. It's not reasonable to have the last person who said, "I don't know, you decide!" decide for everyone on the cycle because she already declared her inability to decide. Consider that everyone on the cycle similarly declared their inability to decide, so the collective cannot decide, and thus they all abstain.
You are right, a delegation cycle just means abstention for all those involved, but it gets tricky when choices or delegations are made on sub-elements.
Because person A can delegate to B on element 1.2, B can delegate to C on 1.2
what happens when person C fill the gap, and delegates to A on sub-element 1.2.4???
the delegation from C to A has to become:
then person A can make a choice on sub-sub-element 22.214.171.124
It's just too complex technically, I'm not even sure I got it right on the above, luckily the user doesn't have to see any of this when he is choosing or delegating. It simply "unrolls" in the background.
I just decided to empeach cyclic delegations, as long as I can't come up with something decent...