Black arrows indicate domination (unless a proposal received no votes, in which case it is dominated by everything, and not shown to keep the graph simple). Blue proposals are undominated proposals, the Pareto Front. When graphs appeared few people understood them, or even gave them much notice. They were among the data we provided after the voting has ended. By the time people have forgotten the issue, so it did not really matter. Then in 2012 I was invited to teach at RENA summer school by Alberto Cottica (which most of you know, or should). In this occasion I met Alex Giordano who got me in touch with <Ahref Foundation. A foundation for civic studies. I gave a talk over there on eDemocracy. And after this talk they expressed interest in funding a rewriting of Vilfredo, trying to make it a professional decision making tool. Still keeping it open source. We decided that the new Vilfredo would have been in Python, with Flask (micro framework), with a fully separated front end and back end. We call it Vilfredo-reloaded, and I think the back-end is now ready along with the API REST.
In the meantime Vilfredo kept on changing. We added feature, smoothed out problems. One of the main changes was permitting to people to see the temporary result of the vote just after they have voted, and in case change the vote. This sort of iterative voting is a revolutionary act, and is based on the idea that in any case people will vote strategically. By letting people iterate the vote they can look for the vote that let them reach the Pareto Front that best represents their desires. And if all people do that, we reach a Nash Equilibrium among the space of possible pareto fronts. And if you have 10 proposals, the space of possible Pareto Fronts have (2^10)-1 possible Pareto Fronts. So it is huge. We are effectively selecting something out of a very big sample. When we do this, participants can see the graph, and see the graph change as they and others, change their vote. Suddenly the graph came alive.
Another change we did was to make the default vote as support (before it was un support). One of the little changes that we suspect helped us push the upper limit on how many people can participate before clogging the system. We introduced icons to vote. Introduced a request for people to write why they did not support something. And even the possibility to explain if you did not support something because you did not agree with it, or you did not understand it.
Key players were also added. Right now I am just making a list of features. But each point would deserve a post by itself, and a discussion. I will try to do it in the next days.
Finally, more recently, I was invited again to speak at the RENA summer school. They actually gave me much more time, which permitted us to organise a Vilfredo experiment with (or on ;-) ) the students. It was the response from those 30+ students that convinced me that it was time to resuscitate this group.
Vilfredo has a lot of work that still needs to be done. But groups are starting to ask how to use it, and if they can use it for themselves. We, on the other side, need test cases. Need a new UI (user Interface). One that is designed by professional people who design complex UI for a living, and that also understand the logic behind Vilfredo. Reading a tutorial is not enough.
I would invite everybody to start a new thread to present themselves. Say what has lead them to Vilfredo. And what can Vilfredo do for them and what can they do for Vilfredo.