Hello,
(I cross-posted this message to http://www.wechange.org/node/97 . I will be updating the remote version with link, corrections, etc, so see there for updates if your read this long after I posted it).
I would like to introduce you to a php voting API that I wish to develop further and for which I'd like to create a Drupal module. It is a complementary alternative or even replacement to the Drupal voting API.
Please, don't consider having a heart attack just yet. Please, read further and decide later.
Allow me to start from the beginning...
A world of alternative voting systems
It is a sad fact that for most people, whenever they think about voting or election, they can only think about what is known as "plurality voting", the voting method whereby you can only select one choice among many. Unfortunately, this voting method is demonstrably very bad.
I am sure that most of the subscribers to this "Voting Systems Drupal Group" know about the main alternative voting methods: Approval voting, Condorcet voting, Cardinal voting to name the main better alternatives...
For the benefit of the other people who may not be aware of those alternatives, or would like to know more, here is a list of links:
- The former election methods web site (unfortunately, the current site owner has removed all the articles that together formed a nice introduction to voting systems like Condorcet, Approval, etc... But you can still browse the site in the web archives.)
- Citizens for Approval Voting and its sister site Americans for Approval Voting provide a simple introduction to Approval voting.
- Movie Night! (or, "how political parties form and screw everything up.... and how to fix it"): entertaining introduction to Condorcet.
- Wikipedia article on Condorcet Voting.
- Casting a Condorcet ballot: another simple introduction to Condorcet (written for the phpBB MOD).
- The Condorcet Matrix: understanding the Condorcet Matrix: a simple explanation.
- Electorama: a portal for election method enthusiasts.
- The Election Method mailing list is probably THE mailing list to join if you're interested in in depth theoretical discussion on election methods. There are other interesting mailing lists more focussed on campaigning and promoting those alternatives.
- Electowidget: a voting methods php API: more on this one below.
- Wechange.org: as the owner of the site, I would like to eventually host a major section of the site devoted to Alternative Voting Methods educational outreach.
My first programming project: a phpBB Alternative Voting MOD
Many, many years ago, but still within our galaxy, I somehow got involved in creating an alternative voting MOD for phpBB for the benefit of a new community. The community didn't make it past the original enthusiasm created by the announcement, but, as fate would have it, I found myself to be the sole developper and maintainer of the phpBB MOD.
This was my first (well, second actually) php project. You can see the MODded phpBB2 forum. If you discount the bugs that were introduced during the last phpBB upgrade, the MOD works well and supports Approval and Condorcet voting in addition to Plurality voting.
Yet, the MOD is mostly a failure, because it is hard to install (like any large phpBB MOD), and despite some demand, it has not been installed on other forums. I failed to reach the educational goals I had set for myself.
(Speaking of phpBB, I am now the maintainer of the phpBB to Drupal migration module).
The educational challenge
As I pointed out above, sadly very few people are aware that there are a world of alternatives beside Plurality Voting. There are scores of proprietary and Open Source/Free CMS, BBs, etc, that have a voting or polling 'module'. All of those, without any exception, default to Plurality Voting. Very few give other alternatives (and Approval voting is the most common alternative, when there is one, like in Drupal 4.7, I believe).
For people like me who believe that better voting systems could go a long way towards ensure that better public servants get elected, the challenge is to reach out to the hundreds of millions of internet users. Today, 'polls' are a popular feature in most web sites, and it's hard to browse the web for a day without encountering one of those polls but almost all (if not all) of them use Plurality Voting even though in most cases Approval Voting would have been a much better choice given the questions being asked. I would like to take up the educational and programming challenge to increase the chances that netizens will find polls using something other than Plurality Voting.
As an example the poll that greets us on the front page of this group uses Plurality Voting: I can chose only one of the three choices given even though two choices (even three if stretching a bit) would have been applicable to me. In this case like many others, Approval voting would have been a better choice. (It's not a criticism of the poll creator, it is just symptomatic of a much wider problem.)
ElectoWidget: a portable php Voting System API
ElectoWidget could well be part of the solution to this challenge. It is a class of objects written in php supporting a complete range of voting methods. It has been written from the ground up to be a portable set of php API to be used with any php-based CMS or BB. However it is still an early Alpha release. It works well with MediaWiki but the UI needs work.
I have started to improve the API so that creating a new Approval or Condorcet poll is easy even for the regular netizen. While the original API works with MediaWiki, my primary aim is to create the classes necessary to make it work as a stand-alone software, and with phpBB and Drupal (I already have a beginning of a Drupal module which works with ElectoWidget, but it's not much, yet).
It is important to understand why a project like ElectoWidget is critical: not one CMS/BB has a very good support for alternative voting systems. Everything remains to be coded. It would be a shame to code completely separate solutions for each and every CMS/BB (like I did for phpBB) when one good API in php can serve all the php projects out there, including of course Drupal.
ElectoWidget was conceived by an Election Method expert and already caters for all the main election methods and many exotic ones (Schulze method, Instant runoff voting...): it's the ideal tool for Election Method experts and enthusiasts, and it's only a matter of UI to make it easy to use (without option overload) for the average netizen.
Electowidget was conceived to be flexible as to the storage system used (either in a database, or as JSON, etc.), the ballot design (a ballot for a given voting system can be designed in many different ways, and of course, Electowidget has been designed to be plugable into any CMS/BB.
A Drupal only solution?
As the phpbb2drupal.module maintainer, I have paid attention to what has been said about phpBB and Drupal. It has often been requested in the past to have phpBB integrated with Drupal, and the standard response was: "we'd much rather improve our own forum". I agreed with that and that's why I tried to make it easy to migrate from phpBB to Drupal (besides, there's now another module that integrates phpBB into Drupal).
I like Drupal a lot, I have been using it for a year for all my web sites (and nothing else) and recommend it around me. I, too, would like that Drupal native modules become better and better.
Still, the world will NOT be significantly different if people use, say, Joomla! or another FOSS CMS instead of Drupal. They are all Free (speech) software and I am happy if people prefer phpBB or PHP-Nuke to Drupal.
Not so with voting systems. It is obvious to me and to many people who are experts in this field, that our society would be much, much better off, if our countries used better voting systems that represent better the will of the people. I, like many others, believe that with Condorcet or Approval voting, much better civil servants would get elected.
All the time spent coding a Drupal only implementation of Condorcet/Approval is time not spent coding the same for other CMS/BB which don't have those features either. As you may understand, from my perspective, promoting better voting methods takes precedence over promoting Drupal. That's why I'd rather spend time coding for an API that can be reused all over the web, rather than coding for an API that will cater for Drupal only.
What about the Drupal Voting API, then?
First of all, what I didn't say is that there's no place for a native Drupal voting API. A Drupal voting API can be used by modules for simple tasks for which ElectoWidget would be an overkill.
It remains to be decided what could be best served by a Drupal voting API, and what could as well depend on the ElectoWidget API. (and if I completely fail to convince you about the use of ElectoWidget, feel free to ignore me: by any means code for the Drupal API and leave me in peace with my naive idealistic dreams... ;-) ).
I would like to avoid replication of code accross all CMS/BB and within Drupal. That's why I hope that we can come up with a good agreement on the respective scope of the two sets of API.
The only thing I hope for the Drupal voting API is that Approval voting is the default voting system used if not specified otherwise. Plurality voting is too much abused as it is.
A note on voting machines
This is a side note.
As a programmer and as a citizen, I am completely opposed to the use of computerized voting machines in any official election. This stance may seem contradictory to my advocating the use of a election method software API. There is however a huge difference: polling software used in CMS/BB could be at best an ideal educational tool: people can learn about alternatives.
But if we want to preserve democracy, it is important that the average citizen can understand the voting method used AND the way the ballots are tallied. Democracy should not be entrusted to the few who have the power and the ability to read the voting software's source code (provided the source is made public in the first place).
I would like to avoid the current American situation: many people doubt that the current American president actually got elected both in 2000 and in 2004. I could provide a list of links to sites explaining why people have some doubts (especially regarding the use of the computerized voting machines used there), but my point here is NOT whether there has been any electoral fraud. Please refrain to voice your opinion on the matter in this forum: it's not the proper venue for that. My point is that the very fact that some people are having doubts about what's hapening within the core of the voting machine (whether those doubts are substanciated or not) is enough of a concern to me.
Whether using Approval or Condorcet or any other method, people should have the right to vote using a pencil and a paper ballot.
The software we are coding together should only be a tool for fun, entertainment or for educational outreach.
So? What next?
As I said, I am already committed to spending time coding for an API that can be widely reused all over the web.
The question is how much the other members of this Drupal group are willing to cooperate with me so that BOTH the general ElectoWidget API AND Drupal can benefit.
Any question about the ElectoWidget API?
How do we make sure we don't duplicate our efforts and spend time separately coding the same features?
What rough road map can be adopted for both sets of API?
Who is willing to help with ElectoWidget?
If you still wish to have a heart attack, you may go ahead, now.
Comments
Some thoughts
First off, welcome to the fray. :-) No heart attacks involved!
Second, the polling options on this site are NOT based on VotingAPI and shouldn't be considered a reflection of its capabilities. ;-)
Third, I think there might be some confusion about the VotingAPI and what it's intended to accomplish. This post from late last year on my blog explains some of the needs that led to the module's development, and what it offers.
VotingAPI does NOT directly provide any voting 'widgets,' polling features, or other tools that are visible directly to end users. Rather, it's a set of shared functions, apis, and data storage standards for other modules to utilize as they implement voting, rating, and decision-management functions. VotingAPI takes in tagged data representing votes, stores it, does some very simple aggregation calculations by default, and then exposes hooks for other modules to implement their own custom 'result-calculation' algorithms.
Why was it written that way? Mostly because a small crowd of modules were starting to appear for Drupal that all offered subtly different implementations of some core voting functionality, but kept re-inventing the wheel in incompatible ways. That made integrating with them difficult, it made it hard to develop other solutions that built on top of them (because everyone was using a different module, it seemed), and it made it difficult to bring enough people to bear on the bigger issue of 'voting solutions' because there were a lot of silos of manpower.
The vision behind VotingAPI is to provide an infrastructure that is flexible enough to support many styles of voting (simple poll-style votes, ranked option voting, multi-criteria product reviews, simple up/down voting ala digg.com, etc etc) while offering a standard set of hooks for retrieving and manipulating both the discrete votes and the overall aggregate results of those votes.
Personally I'd be inclined to work through some of the details of VotingAPI with you, to see if there's any way that we could enhance it to add any capabilities that you feel are missing (as appropriate). If you want to pursue the plan that you've outlined, I think that there's (at the very least) some options for cross-polination between the projects. It'd be a shame to re-invent the wheel yet again. :D
--Jeff
Eaton, Thank you very much
Eaton,
Thank you very much for your considerate reply, and for having taken the time to read and understand my message.
also, I am happy that your heart is solid. :)
There are some obvious overlap and some other equally obvious differences between the VotingAPI and the ElectoWidget API. That's why I had to come out and let you know about it, to figure out what level of cooperation there could be (if any?) between the two projects.
Interestingly, the motivation behind the two sets of API is about the same: let's not re-invent the wheel all the time. The difference is that we are thinking at different levels. You want a set of API that can be reused accross all drupal modules. We want to create a set of API to be reused accross all php-powered CMS/BB.
If you can confirm that, if not Condorcet, but at least Approval voting can already be easily coded using your API, then I don't need to get more involved as you are already doing a good job. What I am concerned about is all the other CMS out there who don't have even this.
To summarize, there are three major differences between the two APIs:
1) as said above, the VotingAPI caters for Drupal only, while ElectoWidget targets all CMS.
2) ElectoWidget is concerned only about creating elections/polls/surveys: store the ballots and calculate the result. The VotingAPI does some extra work in that according to the result a node can be promotted to the front page or not, which is a Drupal-specific function and maybe other stuff like that.
3) the VotingAPI is apparently already production ready, and Drupal module can already use it, while ElectoWidget, unfortunately is still in early Alpha state, which puts me at a disadvantage here :).
I intend to work on ElectoWidget during the next few months. I'll keep you updated on my progress (if any!) and maybe we can figure out along the way how each project affects the other, in more concrete terms.
To reply to your note about storage engine, ElectoWidget uses JSON by default, which is easy because it doesn't use any database. When ElectoWidget gets more stable, if people are inclined to do so, a database storage engine can be added.
There already has been some talk on the dev list about a JSON implementation within Drupal, so some other people are looking into it, too.
I don't know how much you know about Condorcet, whether you had in mind to implement it with the VotingAPI. Maybe for more complex voting methods you can keep an eye on ElectoWidget.
Maybe, eventually, your VotingAPI could be the link between other modules and ElectoWidget...
I guess, I'd better get coding... :-/
A.
--
www.reuniting.info
Healing with Sexual Relationships.
www.wechange.org
We live in a world of solutions.
.
--
www.reuniting.info
Healing with Sexual Relationships.
www.wechange.org
We live in a world of solutions.
yep!
I can say with absolute certainty that both Condorcet and Approval voting are possible using the VotingAPI. Let me offer a quick example of how they would be implemented.
Each 'vote' that a user casts with the API is really a collection of vote objects, each having a tag and a value. In the case of Condorcet voting, there would be one vote object per candidate, with the voter's ranking of that candidate saved as the vote value. If the votes were cast with the value_type of 'points', the API would automatically total up the number of points accumulated by EACH separate candidate. The 'Concordet' module would also be able to implement the votingapi 'calculate' operation to add additional result objects to the voting results cache, explicitly noting the 'winner'.
Approval voting would be even easier -- it would us a similar system, but every vote cast for a candidate would have a value of '1' or '0'.
It's worth noting that in this case, no custom code is necessary for the hypothetical 'concordet' module to implement storage of votes, calculation, or prevention of ballot-stuffing by voters. Implementing the UI for presenting a 'ballot' and a UI for displaying the winner is all it would need to do.
I understand the desire for cross-CMS toolkits, but in my experience only two kinds of APIs work well in that context. The first is calculation-heavy backend code, like an API that does spell-checking. The other is front-end UI widget systems, like scriptalicious or what not. I'd encourage you to take a look, at least, at how vapi handles the 'heavy lifting' and see what it would take to implement with it.
--Jeff
(here’s a quick reply on
(here's a quick reply on your comments made in the two related threads).
Seen from the expert's point of view (I am not an expert but I have a strong interest in the topic), the question of Election Methods is much more complex than it appears at first.
Condorcet being the most complex example, let's consider a Condorcet poll.
The first consideration is the design of the Ballot. Theoretically, it's possible to deduct a condorcet ballot from a cardinal ranking ballot (where each choice/candidate is given a numerical score, e.g. from 1 to 10), but
1- it's far from the best design for a Condorcet poll. It doesn't matter that the first candidate has 8 points, and the second and third only 5. It only matters that the first candidate is ranked above the others.
2- Some (few) argue that a valid condorcet ballot must absolutely rank all candidates, not two having the same rank: we are running here into the problem of validating the ballot (like Plurality voting won't accept 'overvoting' while Approval will).
Besides, people might vote slightly differently according to the design of the ballot(!).
Assuming we now have the stack of Condorcet ballot, the first step is to calculate the condorcet matrix (distribute the value of each ballot into a matrix). But that's only the first step. If we have a Cyclic ambiguity, then we need a method to resolve that ambiguity. The problem is that the experts don't agree on the best method to do that. So, there are many methods which bear different exotic names ;).
That's the use of ElectoWidget: providing a class of objects that can be used from ballot design, ballot storing to calculating the winner according to a variety of voting methods.
I have no doubt that the voting API is well conceived, but the actual modules for condorcet or other voting method still need to be written (for Drupal and other CMS). This means that most of the functionalities still remains to be coded, unless EW is being used.
Anyway...
The bad news (for me and those who would like a full EM implementation) is that I have a few other things on my plate right now. So, at the earliest, it will be a month before I can take up the development of electowidget again. Now that I have told you it exists, I will let you know of the progress I make.
anyone interested in helping with coding can contact me.
Btw, about the poll that just got unpublished: I didn't have time to reply to the message, but I think it's a shame it was unpublished. The poll was not here only for "rhetorical purposes", but for another much more important purpose (as far as I am concerned): it was there for educative purposes. I am convinced that at the very least a few current and future subscribers can learn something from it (using Plurality voting regardless of the poll). I know it's a technical limitation of the core poll.module, but it's still symptomatic of the general ignorance on the topic of EM.
For people really interested in making our world a little bit better, every little bit helps. That's why I regret the poll was unpublished.
--
www.reuniting.info
Healing with Sexual Relationships.
www.wechange.org
We live in a world of solutions.
.
--
www.reuniting.info
Healing with Sexual Relationships.
www.wechange.org
We live in a world of solutions.
First...
...Apologies about unpublishing the poll. I should've waited for more consensus. From what you describe, ElectroWidget could be a very useful tool. Especially the 'encapsulating complex electoral calculation methods' part. Capturing those algorithms in a reusable form is definitely a worthwhile goal.
I think your point about education re: electoral methods is a good one. Do you think it would be possible to construct a poll that illustrates the concept your getting at while still capturing some useful information for the group? 'Which CMS do you use' with a dozen options after it filled the page with empty bars every time someone voted (thus bumping it up to the top of the list). A carefully constructed poll could convey that with only a few questions, I think, and would offer a good (and very focused) illustration of the limitations if properly explained.
Actually, now that you mention it, I've created a new poll for this purpose. I hope it will help as something-to-point to when you're discussing this... :-)
Comparison Ballot
It would be educational to have a ballot matrix of candidates x election methods, and then a comparison of the very different results that various voting methods produce.
La vero vin liberigos.
@eaton : the new poll is
@eaton : the new poll is great. Thanks :)
@simplulo: I saw your comment about the Le Pen / Nader spoiler effect of Plurality voting. Good point.
A comparison of different voting systems has been done on different sites. Check the electorama wiki (link above) or ask in the EM list.
You offered to help. I'll contact you when I need beta testers for EW.
Meanwhile, there are many poll/rating modules authors who are good coders but often have no knowledge of EM (Election Method) theory. That's how we got all the plurality voting poll 'functionality' for each CMS in the first place.
Maybe you or someone else could make a list of all the contrib modules that have a rating component, and list which EM each module uses (cardinal rating being common). Also, we could evaluate the way they use such or such rating method, and advise the maintainers about possible better options.
A.
--
www.reuniting.info
Healing with Sexual Relationships.
www.wechange.org
We live in a world of solutions.
.
--
www.reuniting.info
Healing with Sexual Relationships.
www.wechange.org
We live in a world of solutions.
This would rock.
I find it interesting that the stuff you're talking about is essentially about solving the 'algorithm' problem, while I've focused on solving the 'data storage standards' problem in VotingAPI. I think there's a great opportunity for integration...
Actually..
After reading over your post again, I'm wondering if it might be possible to port ElectroWidget to Drupal using VotingAPI as its data storage/calculation engine.
You might also check out the 'Decisions' module that's been under development for a while. There's not an official project for it yet, but it's in the CVS repository. According to the readme document, their design goals are:
vs. quorum)
It's implemented using VotingAPI. Even if you decide to go forward with your own, I think they might be some good folks to talk to, and their code also offers an example of how the API can be exercised to implement far more complex systems than the traditional 'rate this node' stuff that you're probably used to finding. :)
-Jeff
decisions.module
thanks for letting me know about this project.
The project home page is here: http://drupal.org/node/48244
I just contacted the two main developpers to draw their attention to this discussion.
(Instant runoff voting is a bad election method: it's been used for ages in Australia and, I believe, Ireland, and the result prove the theoretical studies: they are still stuck with a two-party system).
Apparently, they have not implemented Condorcet and Approval voting, yet, but I may be wrong.
--
www.reuniting.info
Healing with Sexual Relationships.
www.wechange.org
We live in a world of solutions.
.
--
www.reuniting.info
Healing with Sexual Relationships.
www.wechange.org
We live in a world of solutions.
Ireland
No, Ireland uses the Single Transferable Vote, and has a great many parties represented in its lower house.
DemExp--A French experiment using Condorcet Voting
Augustin,
Are you familiar with DemExp, in France?
http://www.demexp.org
I just saw a lecture about it, though the lecturer was himself not an expert. As I understand it,
1. Questions are put to the membership to decide via Condorcet Voting.
2. Members can delegate their votes to others for specific types of questions, e.g. by topic.
3. The DemExp collective decision is announced publicly.
They might be able to benefit from Drupal+CivicSpace....
-Steve
La vero vin liberigos.
A Drupal client for the project.
Hello simplulo !
No, I was not aware of it. Thank you very much for pointing it out to me.
It turns out that they were looking for a web client that can communicate with their server.
I have just offered to create the web client using Drupal.
Currently, the experiment works on a hard client (to download and install on one's computer) and a sever. The web client would make it easier for more people to join.
commenting on the three points you mention:
1) the members themselves can ask questions about policy to all the other members. Each member can add possible answers to that question, and an ongoing Condorcet vote decides the answer adopted by the community.
2) the delegation is not implemented yet, but it is an important feature planned.
3) will be. The experiment is still in the alpha stage and no "official" policy has been announced yet. The building of the web client should accelerate the pace of the experience development.
Hopefully, with a Drupal client, we can have a solid tool ready for the 2007 French electoral year, and the 2008 American one.
Thanks again for the information.
For those interested, I will write (in French) a comparison between the two softare projects: electowidget and demexp. I'll post the link in the French Drupal group when it's done.
A.
--
www.reuniting.info
Healing with Sexual Relationships.
www.wechange.org
We live in a world of solutions.
.
--
www.reuniting.info
Healing with Sexual Relationships.
www.wechange.org
We live in a world of solutions.
Drupal client for DemExp
Brilliant!
La vero vin liberigos.