This is a copy of a message I posted in the Drupal Voting API group
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:
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.