Because I'm retiring from voting-systems, and hence from EM, I'm now mentioning a few suggestions that I've made on EM, during my most recent duration of EM membership.
1. Voting X over Y: I posted two precise and useful definitions of voting X over Y 2. FBC: I posted a definition of FBC to replace my previous ones: For the purpose of this definition, top-voting a candidate means not voting anyone over hir. If no candidates would win, other than ones top-voted by you, then, if you raise one or more additional candidates to top, that shouldn't cause anyone not top-voted by you to win. [end of FBC definition] 3. Method properties: As always, I've emphasized certain method properties that avoid the worst strategy problems. For a long time, I've claimed that favorite-burial incentive and the Chicken Dilemma are the important strategy problems, and the ones to avoid. I advocate not using or proposing methods that fail FBC (as I most recently defined it). Approval and Score meet FBC. I suggest that there is no justification for using or proposing a method more complicated or more difficulty-implemented than Approval and Score, unless that method avoids the Chicken-Dilemma (is defection-resistant). Though the Chicken Dilemma is the 2nd most important strategy problem, it isn't nearly as important as favorite-burial incentive. Approval and Score, though they aren't defection-resistant, and therefore have the Chicken Dilemma, can easily deal with the Chicken Dilemma. It isn't a major or unsolvable problem with Approval and Score. Because of the count-fraud problem, I suggest that nothing more complicated or computation-intensive than Approval or Score should be proposed or used in public elections. Approval and Score are suitable for an easy and count-fraud-secure handcount. For informational polling, I propose ICT and (especially) Symmetrical ICT, because they have the abovementioned desirable properties. Additionally, Symmetrical ICT meets Later-No-Help (LNHe), thereby avoiding bottom-end strategy incentive. Regarding the Condorcet versions that define "beat" only in terms of the number of people ranking X over Y, and the number ranking Y over X, I call those "unimproved Condorcet". The unimproved Condorcet methods Fail FBC and aren't defection-resistant. If, someday, there were to come a day when automated counting, and maybe machine voting, could be fully count-fraud-secure, then ICT or Symmetrical ICT would be a good method to propose for official public elections, as regards merit (But no rank method is as enactable as Approval). I should mention, here, two ways in which most EM members and I disagree: a) I've consistently emphasized strategy criteria, criteria that are about freedom from certain strategy-needs. ...those, as opposed to aesthetic criteria. b) I've emphasized the desirability of actual societal results and improvements, as opposed to interminable debates about which rank-method is the best (...debates in which methods are justified by criteria used without justification). Because Approval meets FBC, and can deal with the Chicken Dilemma, and is the minimal, obvious, natural improvement on Plurality, and, in fact, consists of nothing other than Plurality with the repeal of Plurality's ridiculous, anti-democratic, and probably illegal, forced-falsification rule (about which I've said more, here and at Democracy Chronicles), Approval is the obvious choice for the voting-system reform proposal, to achieve b), above. I've pointed out that (and told why): a) ICT and Symmetrical meet the Condorcet Criterion, when that criterion uses a definition of "beat" that interprets equal-top and equal-bottom ranking consistent with the intent, wishes and preference of voters voting in that way. b) FBC and Condorcet's Criterion are not incompatible, under the condition referred to in the previous paragraph. 4. I've proposed Symmetrical ICT, and posted pseudocode for a count-program for it. Pseudocode doesn't favor or disfavor particular languages, and can easily be copied into any programming language by someone familiar with that other programming language. (Improved Condorcet was introduced by Kevin Venzke. It's the top-end counterpart to the Power Truncation that I'd proposed at EM. ICT was introduced by Chris Benham. Symmetrical ICT treats both top and bottom end as ICT treats top end. But it differs from Power Truncation in that, unlike Power Truncation, it applies to all bottom-voted candidates, not just truncated ones. You bottom-vote a candidate if you don't vote hir over anyone.) 5. I posted a definition of a criterion called "Co-operation/Defection" (CD), which was intended to measure for avoidance of the Chicken Dilemma. It's in the archives somewhere, at some time during the duration of my current EM membership. I haven't been using CD, but have instead been referring to the Chicken Dilemma by examples of it. I never completed a thorough check of CD, but it's probably precise and useful as it stands. The purpose of CD was to have a precise, brief and explicit measure of the Chicken Dilemma. 6. Forest Simmons introduced an interesting and clever solution to the Chicken Dilemma, for Score, but easily (probabilistically) adapted to Approval. I call it Strategic Fractional Ratings (SFR). I've recently posted, here at EM, some suggested formulas for SFR. Additionally, I've posted a summary of the various ways of dealing with the Chicken Dilemma. 7. I proposed MTA, a variation of Forest's MCA. I don't know that MTA is an improvement over MCA. MCA is simpler to define, and maybe better. I later proposed MTA2, which is definitely better than MTA. Then I proposed Bucklin2, a version that applies MTA2's improvement to Bucklin. In this paragraph, when I say "Bucklin", I refer to ER-Bucklin, which I've called ABucklin. Bucklin is a generalization of MCA to unlimited rankings. I don't recommend ABucklin, because its unlimited rankings don't achieve the promise of unlimited rankings. MCA is a better proposal. 8. I pointed out that MCA, MTA, MTA2, ABucklin and ABucklin2 could be offered as _ballot-management-options_ in an Approval election. Obviously, options are a lot more proposable and acceptable, in comparison to new and different methods. 9. Additionally, I introduced the conditional methods--conditional versions of Approval, MCA, MTA, MTA2, ABucklin, and ABucklin2. Those conditional versions are, likewise, suitable to all be offered as ballot-management options in the same Approval election. The conditional methods achieve defection-resistance. I discussed several ways of implementing conditionality-by-mutuality (reciprocity). My favorite was the one implemented in MTAOC, for which I posted pseudocode. I described optional-conditional (OC) versions of all of the Approval ballot-management options that I'd proposed. The conditional methods suffer from the disadvantage that they're computation-intensive, and therefore not well adapted to handcount, and are therefore prone to count-fraud, as are the rank methods. ICT and Symmetrical ICT achieve defection-resistance more neatly, and better, than do the conditional methods. 10. I proposed a combination of Score and MCA (or MTA2). The voter could make hir Middle ratings fractional. Of course it would be more complicated, and therefore less proposable, than Score or MCA or MTA2. Choosing between Score, vs MCA or MTA2, as the first improvement on Approval, I'd suggest Score. That's because the strategy for MCA or MTA2 is far from obvious, and never was solved at EM. And Score is more simply proposed, defined, explained and easily implemented.Also, Score's easy SFR capability seems more valuable than MCA's or MTA2's majority-check. Recommendations: For public proposals for official public elections: Approval. Maybe Score if it's liked. Because of its easier SFR capability (without need for probabilistic voting) I like Score, but it's probably not as proposable or enactable as Approval. I've described probabilistic procedures for SFR in Approval. For informational polling: ICT, or better yet, Symmetrical ICT. As I said, I've posted pseudocode for a Symmetrical ICT count-program. Voting in organizations, committees, academic departments, etc: I feel that the choice of voting-system for those applications should be made with regard for providing use-precedent for the best public proposal That's Approval, or maybe Score. So I'd suggest that Approval, or maybe Score, should be used for organizations, committees, academic departments, etc. But if something fancier is insisted on, or if a rank method is insisted on, then I'd suggest ICT, or, better yet, Symmetrical ICT. Michael Ossipoff . ---- Election-Methods mailing list - see http://electorama.com/em for list info
