Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cwjcc!hal!ncoast!allbery From: allbery@NCoast.ORG (Brandon S. Allbery) Newsgroups: news.groups Subject: Re: CALL FOR DISCUSSION: New Voting Rules Message-ID: <1989Oct24.015705.21256@NCoast.ORG> Date: 24 Oct 89 01:57:05 GMT References: <361@nisca.ircc.ohio-state.edu> Reply-To: allbery@ncoast.ORG (Brandon S. Allbery) Followup-To: news.groups Distribution: usa Organization: North Coast Public Access UN*X, Cleveland, OH Lines: 104 As quoted from <361@nisca.ircc.ohio-state.edu> by bernstei@hpuxa.ircc.ohio-state.edu (Dan Bernstein): +--------------- | How about the following changes: +--------------- The system is considerably more complex than the current one, and people seem to have enough trouble following *those* rules at times. +--------------- | name list. At least three days after the initial NAME CHECK is +--------------- Not everyone is capable of, or runs, NNTP. At absolute MINIMUM it should be a week; two weeks is better. +--------------- | 5. Finally, the vote taker should subtract the total NOs from the | total YESs, separately for each name; if the name with the highest | margin has that margin 100 or greater, the group passes with that | name. Otherwise, the group fails. +--------------- This is susceptible to divide-and-conquer, whereby enough yes votes exist to create the group but they are divided over a number of names which individually do *not* have enough votes to succeed. This means that a group for a given topic might fail despite a clear majority for the group. +--------------- | 7. (This is a big jump:) If the question of moderation versus | nonmoderation is not settled during the discussion period, it | should be handled just like the question of names. +--------------- Were there a *simple* way to handle it, quite possibly. As is, no. Why not just hold a pre-vote on name and/or moderation status? +--------------- | rec.aquarium YES3 (YES^3, 3 YES, YES YES YES, or whatever) +--------------- AARGH!!! Imagine counting 1000 votes *by hand* because each voter used her own variant of this. +--------------- | And so on. The idea is that the voters can precisely express how | happy they'd be with each name. +--------------- It doesn't really cover the case where I vote against a name but don't want to vote for any specific group name too well. In particular, a voting system allowing any of {1yes/1no, 0yes/1no, 1yes/0no} is less than fair. How about a 50/50 system? (and the complexity increases...): 0.5yes/0.5no instead of 1yes/1no in the above summary. Still, correcting this glitch adds even *more* complexity to a system which is too complex already. +--------------- | C. There should be some way to deal with idiots who submit a hundred | different names for a group, and shout ``illegal vote!'' if the | vote taker ignores them. Will this be a problem? Also, is three days | long enough to make sure that write-in names get in? +--------------- (1) 1/100th of a vote isn't likely to count for much either way. (2) If she submits 100 votes, it's a pretty good chance that 90 or more are write-ins. You *did* say that write-ins could be ignored.... As stated above, three days is NOT long enough. You've just disenfranchised the UUCP contingent. +--------------- | D. I don't think wildcards are worth the fuss: it doesn't take that long +--------------- Wildcards are yet more complexity. Forget 'em. +--------------- | F. Should there be a way to vote, e.g., with all the YESs having weights | under 1? How often are people only slightly satisfied with any of | the names---but satisfied enough to say YES? Does that even make | sense? +--------------- Hoooooooo boy. Shall we release a 1000-page explanation of the Usenet Voting Guidelines after implementing all of this? +--------------- | F. Is this simple enough for the typical novice voter to understand? +--------------- H*ll, you've got *my* head spinning. Too complex and you disenfranchise the novices as well. (Although I daresay it might be argued by some that they ought to be disenfranchised until they learn the ropes.) Capsule summary: too complex. ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@NCoast.ORG uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu bsa@telotech.uucp 161-7070 (MCI), ALLBERY (Delphi), B.ALLBERY (GEnie), comp-sources-misc@backbone [comp.sources.misc-related mail should go ONLY to comp-sources-misc@] *Third party vote-collection service: send mail to allbery@uunet.uu.net (ONLY)*