Skip to content

Latest commit

 

History

History
95 lines (46 loc) · 6.46 KB

fairparticipation.md

File metadata and controls

95 lines (46 loc) · 6.46 KB

Fair Participation.


The Idea

One of the basic principles in eDemocracy should be Fair Participation.

I gave (together with Cyril Velikanov) a talk on Fair Participation in 2011. You can see it on my webpage.

The basic idea is: How can we make a system where everybody has the possibility to have his voice heard?

This is rooted on an issue of human fairness, but not only. We need to be able to give to everybody the possibility to speak because anybody can have the solution to the question we are asking. And because each person represents a different point of view. And often avoiding hearing a person becomes avoiding hearing a point of view.

What we ant to have is a system where the best solutions are extracted independently of who wrote them. The system should not have any bias on the base of the richness of the person, how socially connected he is, when does he write his proposal and so on.

Let us look at two particularly common, problematic, cases:

  1. In many modern eDemocracy system each proposal has an URL associated to it. And by going to that URL a person can vote for that proposal. This results in people sending a link to all their friends, asking them to vote for him. Then the voting stage stops being an evaluation of which proposal is best and becomes a popularity contest.

  2. In many websites where different proposals are presented and evaluated, the proposals are also listed in order of popularity, and in order of novelty. The result of this is that the proposal in the popularity list end up having a massive amount of vote. They are presented to the voters so often it is unavoidable they gather those votes. This does not depend over the content of those proposals, but over the fact that those proposals were presented before the others. At some point the latest proposal in the list of the most popular proposal, will have gathered more voted than any proposal can possibly gather in the time is remains in the novelty list. Before it is deemed too old to be in that list. At that point the evaluation is effectively over. No new proposal can possibly win. The problem with this system is giving a list of best proposals. Or, more precisely, giving a list of best proposals where it is possible to vote.

    • NOTE: there are some websites who try to avoid this by adding another list: the Hot proposals. Which are the proposals that are growing faster than others. This is done (usually) by looking at the first derivative of the proposals, and seeing which proposals grow faster. This is effectively like adding a bus that moves from the novelty list to the popular proposals list. Now the limit to the evaluated proposals is given by the size of the bus.

Information which is usually better not shared during the evaluation stage

Although Transparency is a great thing. And necessary to our democracy. There are some information that if shared too soon can compromise the fairness procedure. I am listing in some other parts of the document a list of situations

  • The URL address of a proposal

  • The author of a proposal

  • The number of votes a proposal has received

  • The rank of a proposal over the others

  • Who votes for the proposal

Essentially the more the people who vote for a proposal have information about the proposal, over and beyond the content of the proposal. The more biased their evaluation can become (and statistically in some situations will be). Each proposal should stand on its two feet. And be evaluated on the base of that. You can still share all this information, just it must be impossible for a person to evaluate a proposal after they have seen the results. Or at least they should not be allowed to evaluate it on that page or immediately after.

Possible Solutions:

Now let us look at various tools and design possibilities that would permit to make a system fair, or at least fairer.

Having no URL associated to a proposal

If having an URL associated to a proposal can help people advertise it, with the effect of making the evaluation of the proposal a popularity contest. Then having no URL should do just the opposit. The proposals might be present in an image and appear when the authors hovers over them with the mouse. Or they can be sent from the author, but with no visible easy to reach URL.

Positive Aspects:

  • Easy to do.
  • Easy to understand by the users

Negative Aspects:

  • It is generally accepted in modern computing that there should be a URL, or a URI, associated with everything. Denying this possibility might make a system criticised.

  • While people that advertise a proposal to be voted are essentially cheating. They are also doing a service for the system. They are also advertising the system in the whole wide web. Denying this possibility can make a system much less known to the general public.

    • A possible partial solution to this is to let people advertise the question instead of the proposal.

Having URL associated with a proposal, but denying the possibility to people to vote for them at that URL

Polls already do this: the page of the results is not the same page where you can vote.

Positive Aspects:

  • Easy to do.
  • Easy to understand by the users

Negative Aspects:

  • It is still possible for the users to read what are the proposals that are winning, and then go and look for them. Essentially it depends on how hard it is for them to do this that lies how much the system is fair

  • As before: while people that advertise a proposal to be voted are essentially cheating. They are also doing a service for the system. They are also advertising the system in the whole wide web. Denying this possibility can make a system much less known to the general public.

Pushing solutions to readers to let them evaluate them

Instead of having the people going to a proposal, and then asking to evaluate it. A different, and in a sense revolutionary, idea would be to let the person say when they are ready. And then offer them a solution to evaluate.

Positive Aspects:

  • The system can let the users evaluate proposals that has not been evaluated enough. Thus making sure each proposal has been evaluated by the same number of people.

  • The system can also record what solutions has each person seen in the result list, and not offer that solution to that person to evaluate.

Negative Aspects:

  • By making it hard for people to search for solutions, it might increase the number of times similar solutions are presented.