(See DecisionMakingPlugin. This plugins will become one.)
This plugin will create a better way for referenduns inside Noosfero.
Liquid Democracy is a democratic system in which most issues are decided by direct referendum. However, since no one has time for this, you can delegate your votes. The votes on a certain topic you delegate to one person, and then delegate your votes on another topic to someone else. And delegations are transitive; you can delegate to someone who delegates to someone else, etc, in which case your votes will flow to whoever is at the end of the line. Of course, you can “un-delegate” at any time.
Example: You want to vote directly on educational issues, but for environmental issues you delegate your vote to Ana. Ana will vote directly for most of env issues, but about methane limits she will delegate to Bob.
- Issue 1: Education: You vote
- Insue 2: Env - Wales: You -> Ana vote
- Insue 3: Env - cows methane: You -> Ana -> Bob vote
Problems to pay attention
Determining topical boundaries
See Categorization of votes
If we have the issue "Tax meat production to pay for forrest protection"
, how must we categorize this? "gov tax", "industrial taxing", "livestock" or "environment"?
The proposal solution, in communitywiki, for this problem is to have several independent categorization groups and the person must to select a categorizator to have its automatic delegation. That increases the trust dependence...
Other solution is to multiple valuated categorization, when the admins define how much the issue is related to each category, and the system get the first auto delegation on this ordered list. But the evaluation can be, may be or must be done by the political vision of the individual (admin or voter), so this solution will help nobody.
The proposal for this plugin is to allow multiple categorization for issues, like tagging. As any other thing all profile admins may edit and change or add categorizations.
The user will delegate a person for each issue category. When a issue has more than one category, and this delegates for more then one representatives, the selection will be made by the "trust priority order".
When you delegate a category to someone, this person enter on your "trust priority order" list. You can reorganize the list as you wish, but you will always have a list. When you have a representative conflict from the multiple categorization, the most prioritized person will vote for you, with the good old automatic delegation.
So, the example:
- "gov tax" and "industrial taxing" -> delegate to Sr. Madruga
- "livestock" -> delegate to Vegan Association
- "environment" -> delegate to Paul McCartney
- any other -> by myself
Your "trust priority order":
- Vegan Association
- Paul McCartney
- Sr. Madruga
Vegan Association delegates its "environment" votes for IPCC Working Group with highest priority.
For the issue "Tax meat production to pay for forrest protection"
your vote automatically flows:
You -> Vegan Association -> IPCC Working Group
Determining the voters.
The voters are all members of the group profile or all friends of a personal profile.
That is all for now.
Preventing vote selling
The best idea for this seems to be secret ballots. So, you really have to trust the people you delegate to.
Hey! If somebody has the delegation of several voters, if it has a big vote weight, don't must we be able to see his vote?
This question belongs to the current representative model, where a person has no power, but its voice, to make the executive government or legislative actions. Our weapon on this deprecated "democracy" solution is to see the votes of our representatives, to know if they are voting for we or for aside interests.
On the Liquid Democracy you don't must delegate your vote (give your power), if you don't really trust on anybody. You can give it, but you only must if you don't know the theme and you trust enough on somebody.
We have the gangster cliche case: "You vote for me and I pay you, you vote against me and i break you"
. If we display the votes of any person, we put all in risk, but a person with higher vote weight will have a higher and unacceptable risk.
We may argument for some profile types, like associations, it must have all votes opened, because it's members must be able to see if the internal collective was respected. In other case, we may want to trust on a association, but only if it is consistent with its discuss.
Resume: To prevent vote selling we must hide personal votes and display organization votes.
Limit the voting weight for a person
A person with a decisive voting weight is much more susceptible to the "gangster cliche" the other participants. A person with enough power to decide alone is another big problem to the process, affecting the will of other participants. Based on the collective reality the limit voting weight may be 20% of total (for small groups) or 1% of total (for the citizens of an state).
When a person (the guy) receives 50% of it's limit, all next participants who gives its vote to the guy will be notified about the limit and will be oriented to delegate its voting power to another (if it wants). When the guy receives 100% of it's limit, no one can delegate votes to him. Will be nice if all delegators of the guy receive a notification about his big decision weight.
Detecting and dealing with cycles
A delegation circle is something like: A delegated to B who delegates to C who delegates to A.
Any delegation setting must walk on the new delegation tree to see if a circle is possible, and if that is, so: reject it.
When setting the issue, the creator may select a voting method to better express how the real decision must be made.
Yes or No
The boolean issue. Example:
- Issue: "Construct a new subway line from Gaoling to Ba Sing Se"
- Vote options: "Yes", "No"
- you -> "Yes" (for sure)
- Ana -> "Yes"
- Bob -> "Yes"
- Cal -> "No"
- Dee -> "Yes"
We'll build a new subway line from Gaoling to Ba Sing Se!
List - most voted
The issue have a list of (admin defined) options, and the voter must select only one option. The most selected win.
- Issue: "The best avatar is:"
- Vote options: "Aang", "Korra", "Cameron's Avatar"
- you -> "Aang" (for sure)
- Ana -> "Korra"
- Bob -> "Aang"
- Cal -> "Cameron's Avatar"
- Dee -> "Korra"
- "Aang": 2
- "Korra": 2
- "Cameron's Avatar": 1
We'll have a second turn with "Aang" and "Korra".
We must consider to only use the "most voted" method when we have only two options. See the "ordered preference" method to understand.
List - ordered preference (simple)
The issue have a list of (admin defined) options, and the voter must order its preference. The better average win.
- Issue: "What bending must be prioritized on schools?"
- Vote options: "water", "earth", "fire" and "air"
- you -> 1:"earth", 2:"water", 3:"fire", 4:"air" (for sure)
- Ana -> 1:"water", 2:"earth", 3:"air", 4:fire""
- Bob -> 1:"fire", 2:"earth", 3:"water", 4:"air"
- Cal -> 1:"fire", 2:"air", 3:"earth", 4:"water"
- Dee -> 1:"air", 2:"water", 3:"earth", 4:"fire"
- "water": 2 + 1 + 3 + 4 + 2 = 12
- "earth": 1 + 2 + 2 + 3 + 3 = 11
- "fire": 3 + 4 + 1 + 1 + 4 = 13
- "air": 4 + 3 + 4 + 2 + 1 = 14
The lower sum means better average position.
If that was a "most voted" selection, fire was the winer, but fire has also a great rejection, so the "most voted" will not make the people happy on this case.
Result: We'll have Toph Beifong as teacher. YEAH!!!
List - ordered preference (Schulze)
May we must drop "ordered preference (simple)" for this better planned.
Proposal way to work
- Any article or forum topic may be a issue to be debated and voted. That is a flag to be set to the article any time.
- The admin must set a period when the system will accept votes. After the period the issue will be closed for voting and will display its result.
- When an article, inside a community or enterprise, is converted on an issue to be voted, all members receives a task inviting to read, debate and vote.
- When an article, inside a user profile, is converted on an issue to be voted, he/she can select and invite it's friends, by the same task system, to participate.
- Each profile is an independent political place. The participants of community A may not be the same of community B, so the delegation flow is not the same. Different communities are like different cities or government levels.
- The profile (community, enterprise or person) will define its "issue themes" where a user may delegate its votes.
- The issue creator can link the issue to one or more "issue themes".
- The user will receive no tasks for voting on issues about themes where it delegates.
- The user can delegate it's vote for all issues inside an profile without need to know the themes.
- The user can delegate it's vote only for a specific issue.
- The user can undelegate it's vote only for a specific issue.
- The delegation interface can be accessed directly from any issue or from the liquid-democracy public-interface for each profile, where you can see the participation statistics for users and its current voting weight for each theme. Caution: Protect the user privacy.
- The user can manage it's delegations and see it's history on the liquid-democracy private-interface. Do not display the user vote to protect the user from information thieves.
- all issues in the house: Delegate all issues on profile X to user Y
- all issues of a theme: Delegate all issues on profile X from theme K to user Y
- one issue: Delegate the issue z to user Y
Similares Web Service with Schulze Method and others links