Introduction

We where looking for an algorithm that could be used for the voting on project documents (basically proposal documents). These documents have to be accepted or rejected. A few requirements where drawn for this voting algorithm:

• It shouldn't too easy or too hard to accept/reject documents. Accepting or rejecting too quick would not allow enough input by the community, and too slow would make Truetopia inefficient.
• It should provide simple, transparent and effective control parameters to tune the process. (no black box algorithms)
• It must be easy to understand how it works.

A system with pro and con votes (pro counts as +1, con as -1) is in many ways preferable, because: it expresses the voters opinion better, it allows for the calculation of a vote balance (sum of all votes, that can be positive or negative) and it enables 'counter vote campaigns'. ^{[todo: find some papers on the difference between voting schemes]}

Why not ...?

Why not have a fixed voting time frame (lets say of 2 months per vote)?

In that case documents can be accepted/rejected on very small margins.

Why not have a treshold of value (lets say 10000 'pro' votes for accept, or better 5% of the total of members)?

That way very popular items can reach a decision (too) quick, where not popular items will probably never meet the treshold and therefor stall the process.

The 'platform' algorithm

We first learned about what we call the platform algorithm from the party program (Swedish version) of the AktivDemokrati party in Sweden. This party sets requirements for the web application they are trying to build, similar to the requirements of Truetopia. The AktivDemokrati party and the Truetopia project are in close contact and have an open road ahead for future collaboration. Our main difference is that Truetopia is building the web application first, and anticipates that a community driven by the Truetopia web application will collaborate on creating a political party. Where the AktivDemokrati] party is a political organization that wants to build a web application.

The AktivDemokrati] party describes a process they name 'continuous voting'. In this process the accepting/rejecting is done through the size of the surface under the vote balance graph -- this surface we call the platform.

If the platform is measured against the size of the member population using a factor we name the throttle parameter. If a positive platform multiplied by the throttle parameter is bigger than the member population a document is accepted, in case of a negative platform x throttle is bigger than the member population a document is rejected. When the vote balance is switching from positive to negative, or vise versa, the platform is reset to zero.

The advantages of this algorithm are numerous.

• There is no fixed time frame: popular votes can reach a decision quick, where not-so-popular votes will take more time.
• Both popular and less popular votes will be able to reach an outcome (accepted/rejected).
• Counter voting campaigns are possible and very effective.
• It allows simple, straight-forward and transparent control over the average time a vote runs using the throttle parameter. Raising the value will make votes reach an outcome quicker, whereas lowering the value will allow votes to run longer.

About this page

This page is by no means finished. It just outlines the concept of platform. The text is too technical and needs some graphs to clarify. The AktivDemokrati party program gives some more information.

Sorry for the incomplete information, you are welcome to contact us for clarification.