woods@ncar.ucar.edu (Greg Woods) (10/20/89)
Recently we have all seen a lot of new voting schemes suggested whose major goal (and a laudable one) is to provide a way of resolving controversial naming issues. Without exception, they all solve this problem but without addressing one crucial issue that is paramount: VERIFICATION. The only reason why the current voting scheme works (by "works" I mean that most site admins on the net are willing to abide by the results of it) is that it is easily VERIFIABLE. When the votes are posted, anyone on the net can make sure their vote was tallied correctly (and in the case of an admin, even trouble themselves to see that votes cast by their users were for real), and anyone who can run "wc -l" can verify that the ballots posted do in fact lead to the stated result. In other words, the tools required for verification are supplied with at least many versions of UNIX, which means that they can be checked by a LOT of people. With these "multiple vote" schemes this will no longer be the case. For one thing, the bandwidth required to post the results will now increase by an order of magnitude, as will the complexity of the process needed to verify the results. No longer will a simple "wc -l" suffice; specialized software would be required. Putting aside my personal views on voting and the namespace, and putting on my "single site administrator" hat, I would be reluctant to accept the results of votes that cannot easily be verified, or where the only verification comes from someone with a vested interest in the result (i.e. the vote-taker). For these reasons, I am convinced that multiple-vote schemes are unworkable. The name of the group simply must be resolved before the creation vote is taken. I can see two ways to do this: 1) Have a separate vote on the name first. This would work as long as there are only two names in the running (with more than two names, we obviously bump into the same multiple vote verification problem). Since most naming controversies usually revolve around which hierarchy to place the group in, this might work, picking one name in each hierarchy to vote on. The disadvantage is that it will lengthen the creation process considerably for groups which suffer from controversy over the name (which might not be a bad idea depending on your point of view). 2) Have a name czar or small group of czars choose which name to vote on. This obviously requires finding a group of people that the net admins will trust. Unless we do one of these two things, there will not be a workable solution to naming controversies. --Greg
sloane@kuhub.cc.ukans.edu (10/21/89)
In article <4771@ncar.ucar.edu>, woods@ncar.ucar.edu (Greg Woods) writes: > Recently we have all seen a lot of new voting schemes suggested whose major > goal (and a laudable one) is to provide a way of resolving > controversial naming issues. Without exception, they all solve this > problem but without addressing one crucial issue that is paramount: > VERIFICATION. The only reason why the current voting scheme works (by > "works" I mean that most site admins on the net are willing to abide by > the results of it) is that it is easily VERIFIABLE. You make an very good point here. While I would be willing to accept your verification of the vote, perhaps others wouldn't. OK, suppose we accept Alien Well's method. As I understand it, he proposed that the call for votes would contain a list of possible group names, and voters could vote YES or NO for any or all of the groups mentioned. A table would be compiled of the YES/NO votes, and some selection criteria applied to decide if the group gets created, and what name it should have. The results of the voting would be posted as follows: YES NO sci.lith-dogs 123 98 rec.lith-dogs 142 23 rec.pets.lith-dogs 147 4 ... Then the list of voters could be posted in the following form: group.name1 yes_or_no voter_name <voter@address> group.name2 yes_or_no voter_name <voter@address> group.name3 yes_or_no voter_name <voter@address> ... Now I am no unix guru, but couldn't you verify the vote by doing something like using grep to find all the yes votes for a specific name and piping that into wc -l? Maybe something like: grep "^sci.lith-dogs *yes" file >wc -l grep "^sci.lith-dogs *no" file >wc -l grep "^rec.lith-dogs *yes" file >wc -l ... Never having used unix, I can't be sure, but I suspect that this wouldn't be too hard to do. I suspect I could find a way to do it on VMS, so I am sure unix could handle it some way. Yes, I realize that the size of the vote results would go up, but I think an order of magnitude is a little pessimistic. Wouldn't it just be multiplied by the number of names under consideration? Right now we send in one line per voter for 1 group. Under the new scheme, we would send in one line per voter per group name. In the aquaria case, this might be 5 or 6 possible name, but usually it would only be 1 or 2. In any case, would the increase in traffic be more or less than the traffic generated by the flame wars over the name? Just how much traffic is generated by vote summaries? Would making them an order of magnitude larger really be the bad if it reduced the flamage over the name selection? -- USmail: Bob Sloane, University of Kansas Computer Center, Lawrence, KS, 66045 E-mail: sloane@kuhub.cc.ukans.edu, sloane@ukanvax.bitnet, AT&T: (913)864-0444 "The scientific theory I like best is that the rings of Saturn are composed entirely of lost airline luggage." -- Mark Russell
peter@ficc.uu.net (Peter da Silva) (10/21/89)
Verification. Yes, a good point. And a good argument for the Alien Wells scheme. It would be easy enough to list the votes without a lot of bandwidth: ---------- "PROPOSAL: discussions of War of the Worlds, the TV show" The winner was "rec.arts.wotw" with 110-34. Because this did not meet the 100 vote majority the group was not created: YES NO 1 rec.arts.wotw 110 34 2 sci.space.wotw 1 172 3 rec.arts.tv.wotw 87 1 4 rec.arts.war-worlds 102 34 Votes: 1 2 3 4 Name Y - Y Y peter@sugar.hackercorp.com (Peter da Silva) Y N Y N peter@ficc.uu.net (Peter da Silva) N Y N N sexton@gryphon.com (Richard Sexton) ... ------------ There is another alternative to creating a Name Czar or going to a more complex scheme... that is, forcing people to worry more about opposition to the name. This would cut down the "I know I can get 600 votes so I'm gonna call it comp.lang.piglatin, so there" type stuff. Either the BADNAME vote proposal or my 100 NO vote proposal would serve this purpose. -- Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation. Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-' "ERROR: trust not in UUCP routing tables" 'U` -- MAILER-DAEMON@mcsun.EU.net
chuq@Apple.COM (Chuq Von Rospach) (10/21/89)
> For these reasons, I am convinced that multiple-vote schemes are >unworkable. I agree with Greg on this... > I can see two ways to do this: 1) Have a >separate vote on the name first. >Have a name czar or small group of czars choose which name to vote on. >This obviously requires finding a group of people that the net admins will >trust. Greg forgets (3) which I suggested early on. A person who feels that the name is incorrect sponsors their own separate voting on the preferred consensus name. It is run in parallel, removing the delays on voting on the name. The alternate name would be generated by consensus and not by a net.czar, removing the mostly irrational fears about net.gods going crazy and taking over all the free world. It doesn't add serious delays, lots of complexity, is verifiable and doesn't focus excess power in the hands of a few megalomaniacs like me. It also guarantees (mostly) that naming arguments won't be done spuriously, since it requies someont to put up and run an election, which isn't likely to happen for silly reasons. chuq -- Chuq Von Rospach <+> Editor,OtherRealms <+> Member SFWA/ASFA chuq@apple.com <+> CI$: 73317,635 <+> [This is myself speaking] Trust Mama Nature to remind us just how important things like sci.aquaria's name really is in the scheme of things.
newsuser@lth.se (LTH network news server) (10/21/89)
In article <6618@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: (example of vote verification format) >1 rec.arts.wotw 110 34 >2 sci.space.wotw 1 172 >3 rec.arts.tv.wotw 87 1 >4 rec.arts.war-worlds 102 34 > >Votes: > >1 2 3 4 Name >Y - Y Y peter@sugar.hackercorp.com (Peter da Silva) >Y N Y N peter@ficc.uu.net (Peter da Silva) >N Y N N sexton@gryphon.com (Richard Sexton) This is a very good proposal! It gives all the information, and it's also compact (and can be checked). How was it now about the votes? The name with the biggest margin wins, and this margin must be > 100? -- Bengt Larsson - Dep. of Math. Statistics, Lund University, Sweden Internet: bengtl@maths.lth.se SUNET: TYCHE::BENGT_L
bee@cs.purdue.EDU (Zaphod Beeblebrox) (10/21/89)
Said peter@ficc.uu.net (Peter da Silva): (in article <6618@ficc.uu.net>) | | [ ... ] | |Votes: | |1 2 3 4 Name |Y - Y Y peter@sugar.hackercorp.com (Peter da Silva) |Y N Y N peter@ficc.uu.net (Peter da Silva) |N Y N N sexton@gryphon.com (Richard Sexton) |... Actually this type of format could be used very easily to report the modified STV (STV + "NO GROUP") that has been proposed. Instead of Y or N or -, put down the numerical position of the group in that voter's preference list. If "NO GROUP" is nowhere in the list, then the others would be reported as -, indicating no support or opposition for that group. If "NO GROUP" is above a given group, then X is put in the column for that group, indicating opposition to that name. Hence the above might look like: Votes: 1 2 3 4 Name ------- 1 - 2 3 peter@sugar.hackercorp.com (Peter da Silva) 2 X 1 X peter@ficc.uu.net (Peter da Silva) X 1 X X sexton@gryphon.com (Richard Sexton) This would report very succinctly that the following votes had come in: peter@sugar.hackercorp.com (Peter da Silva) rec.arts.wotw rec.arts.tv.wotw rec.arts.war-worlds peter@ficc.uu.net (Peter da Silva) rec.arts.tv.wotw rec.arts.wotw NO GROUP sexton@gryphon.com (Richard Sexton) sci.space.wotw NO GROUP Personally I think that the modified STV is the best system by far. It lets me vote for the groups I want, while preferring some names over others. It lets me make sure my vote will not be counted for (indeed it will be counted against) groups whose names I disagree with. It also lets me vote for certain names while expressing no preference either way on the rest. I haven't seen any other scheme that allows all this besides modified STV. B.E.E. -- Z. Beeblebrox | "Some girl with psychic powers asked me, (alias B.E.E.) | 'T-Bone, what's your sign?'; bee@cs.purdue.edu | I blinked and answered, 'Neon'. ..!purdue!bee | I thought I'd blown her mind!" -- _Existential Blues_
mack@inco.UUCP (Dave Mack) (10/22/89)
In article <6618@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >Verification. > >Yes, a good point. And a good argument for the Alien Wells scheme. It >would be easy enough to list the votes without a lot of bandwidth: > >---------- > "PROPOSAL: discussions of War of the Worlds, the TV show" > >The winner was "rec.arts.wotw" with 110-34. Because this did not meet >the 100 vote majority the group was not created: > > YES NO >1 rec.arts.wotw 110 34 >2 sci.space.wotw 1 172 >3 rec.arts.tv.wotw 87 1 >4 rec.arts.war-worlds 102 34 > >Votes: > >1 2 3 4 Name >Y - Y Y peter@sugar.hackercorp.com (Peter da Silva) >Y N Y N peter@ficc.uu.net (Peter da Silva) >N Y N N sexton@gryphon.com (Richard Sexton) >... >------------ A most amusing example, which illustrates the problem with this scheme. It fails to separate the two issues which are actually being voted on: whether or not a group devoted to the topic should exist, and if so, what its name should be. I suggest that this approach be expanded as follows: a vote simply saying "No" or "topic: no" would be considered a vote against the group regardless of its name. Any vote containing "yes" or "topic: yes" and/or a list of name yes/no votes would be considered a "yes" vote for the group. A "topic: no" vote would have no influence on the name vote. Group creation would be based on (topic:yes) >= (topic:no) + 100. The name under which the group should be created would be based on the maximum of (name:yes) - (name:no) with maximum (name:yes) as a tie-breaker. Under this scheme, the group name in your example (assuming the topic vote passed) would have been "rec.arts.tv.wotw". -- Dave Mack McDonnell Douglas Electronic Systems uunet!inco!mack, inco%mack@uunet.uu.net (703)883-3911 All opinions expressed are my own and do not reflect those of MDESC. Ever.
" Maynard) (10/22/89)
In article <35805@apple.Apple.COM> chuq@Apple.COM (Chuq Von Rospach) writes: }Greg forgets (3) which I suggested early on. A person who feels that the }name is incorrect sponsors their own separate voting on the preferred }consensus name. It is run in parallel, removing the delays on voting on the }name. The alternate name would be generated by consensus and not by a }net.czar, removing the mostly irrational fears about net.gods going crazy }and taking over all the free world. It doesn't add serious delays, lots of }complexity, is verifiable and doesn't focus excess power in the hands of a }few megalomaniacs like me. We even have a test case running: the current vote on rec.aquarium. I sent him a YES vote, and suggest that 1) the parallel vote be treated as legitimate and 2) that everyone who thinks that sci.aquaria is misplaced send him a YES vote. -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can jay@splut.conmicro.com (eieio)| adequately be explained by stupidity. {attctc,bellcore}!texbell!splut!jay +---------------------------------------- Send richard@gryphon.com your NO vote on sci.aquaria; it belongs in rec.
brad@looking.on.ca (Brad Templeton) (10/22/89)
All of the proposals share another major fault: complexity. Complexity breeds flaming. It's hard to manage, sure to result in misinterpretation, and increases bureaucracy. I firmly maintain the guidelines have to be made shorter, not longer. -- Brad Templeton, ClariNet Communications Corp. -- Waterloo, Ontario 519/884-7473
" Maynard) (10/22/89)
In article <37123@looking.on.ca> brad@looking.on.ca (Brad Templeton) writes: >All of the proposals share another major fault: complexity. >Complexity breeds flaming. It's hard to manage, sure to result in >misinterpretation, and increases bureaucracy. >I firmly maintain the guidelines have to be made shorter, not longer. How do you propose solving the sci.aquaria syndrome, then? This is a problem which will occur more and more frequently as we go on, unless something is done. Both pre-votes and naming czars will increase complexity, and they have their own problems: pre-voting will drag out an already lengthy process, and name czars will be subject to their own set of flames. -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can jay@splut.conmicro.com (eieio)| adequately be explained by stupidity. {attctc,bellcore}!texbell!splut!jay +---------------------------------------- Send richard@gryphon.com your NO vote on sci.aquaria; it belongs in rec.
brad@looking.on.ca (Brad Templeton) (10/23/89)
In article <2970@splut.conmicro.com> jay@splut.conmicro.com (Jay "you ignorant splut!" Maynard) writes: >Both pre-votes and naming czars will increase complexity, and they have >their own problems: pre-voting will drag out an already lengthy process, >and name czars will be subject to their own set of flames. Pre-votes certainly increase complexity and are clearly not the answer. A name czar is a very *simple* solution, in that it can be expressed in one sentence: "The group champion should then mail to name-server@czarsite and request a name for the group that in the name-server's opinion is the best name for the group." So it's simple, not complex. Now will it cause flames? That can only be told for sure by experiment. It is my opinion that choosing a name is not rocket science. Assuming we want hierarchies (something I am not so sure of) then I think we can define them well, and if they are defined well, I think an independent party can pick a name through a fairly logical process that's not super-subjective. That won't stop somebody from disagreeing, of course. But either their disagreement will be silly, and ignored, or it will be a true borderline case. If it's a true borderline case, we just have to get the message out that in such cases it doesn't matter where it goes, and the name-server's arbitrary decision is as good as any other decision making process. Real-world society hires judges for this purpose to deal with far more difficult questions. It works because we've agreed in advance to respect the judge's decision, even though we all admit that some things could be argued either way. ------------------------ Now this aquaria case is tough. If the name-server had said "rec" then it is possible the "sci" proponenets would have then gone out and taken the argument public etc. etc. But this degenerate case is certainly no worse than we have now. And we would have one answer to give -- "it could be argued either way, but an impartial judge has picked one of the ways, let's go with that." The only mess is if the judge picks wrong too many times and has to be replaced. I think we could find a judge who would not fail in this way. Remember that the planets don't fly off the sun if a group has the wrong prefix. All that matters, if you believe this whole hierarchy thing, is that the choice be consistent. Two currently suggested methods -- group champion selection and voting -- will *not* be consistent.
peter@ficc.uu.net (Peter da Silva) (10/23/89)
In article <37323@looking.on.ca> brad@looking.on.ca (Superuser) writes: > "The group champion should then mail to name-server@czarsite and > request a name for the group that in the name-server's opinion > is the best name for the group." You really think that would have stopped Richard Sexton? Or if not him, someone else who's a little more persuasive? -- Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation. Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-' "I feared that the committee would decide to go with their previous 'U` decision unless I credibly pulled a full tantrum." -- dmr@alice.UUCP
allbery@NCoast.ORG (Brandon S. Allbery) (10/24/89)
As quoted from <2970@splut.conmicro.com> by jay@splut.conmicro.com (Jay "you ignorant splut!" Maynard): +--------------- | In article <37123@looking.on.ca> brad@looking.on.ca (Brad Templeton) writes: | >All of the proposals share another major fault: complexity. | >I firmly maintain the guidelines have to be made shorter, not longer. | | Both pre-votes and naming czars will increase complexity, and they have | their own problems: pre-voting will drag out an already lengthy process, | and name czars will be subject to their own set of flames. +--------------- What, precisely, is wrong with a longer process? alt.all can be used for "quick-pop" (and, occasionally, quick-fizzle) newsgroups like alt.fusion and the recent alt.quake; the mainstream Usenet can put up with a longer process in order to get it *right*. I personally think that a good idea would be a combination scheme: a pre-vote on the name, with names *suggested* by a core group of "name czars" -- only they won't be czars, because their choices will be non-binding; other names can be proposed in the name vote. But in any case, *none* of the schemes really deal with the sci.aquaria debacle; people who explicitly declare that they want a specific name in order to defeat backbones' unwillingness to carry a specific group are clearly abusing the system as badly as the spurious "comp.protocols.tcp-ip.eniac" vote did. Unfortunately, the only solutions to such abuse of the system would abuse it even more, by effectively ending the largely anarchistic nature of the Usenet. (To a lesser extent, similar things are going on in the even-more- anarchist alt hierarchy, concerning alt.sources.) ++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@<backbone>] *Third party vote-collection service: send mail to allbery@uunet.uu.net (ONLY)*
woods@ncar.ucar.edu (Greg Woods) (10/25/89)
In article <37123@looking.on.ca> brad@looking.on.ca (Brad Templeton) writes: >All of the proposals share another major fault: complexity. >Complexity breeds flaming. It's hard to manage, sure to result in >misinterpretation, and increases bureaucracy. > >I firmly maintain the guidelines have to be made shorter, not longer. Brad and I have very different visions of what the net is and should be, so I frequently find myself on opposite sides of debates from him. However this time I think he has hit the nail right on the head. The more complicated the voting procedure is, the more flames over petty procedural issues we will have. Better to save our energies for flaming over something worth flaming about! :-) Some of the counter-proposals in this thread are a little better, because they do address the verification issue. However, now the problem is that the vote results must be posted in a very specific format. This complicates the procedure quite a bit. Instead of flames over the group name, we now will get flames over the format of the voting results. I for one do not consider that to be an improvement. We have to keep it SIMPLE. That's why I like either the NO vote threshhold (again, simple and easy to verify) or having a name czar (or better, a small group of name czars just to prevent one person with an axe to grind from making a big issue out of a single case). I think that simplicity and verifiability are the most important things we need in any new voting scheme. Flexibility of expression on the part of the voters is nice, but not as important as keeping it simple and making it easily verifiable. --Greg
csu@alembic.acs.com (Dave Mack) (10/25/89)
In article <4806@ncar.ucar.edu> woods@handies.UCAR.EDU (Greg Woods) writes: >In article <37123@looking.on.ca> brad@looking.on.ca (Brad Templeton) writes: >>All of the proposals share another major fault: complexity. >>Complexity breeds flaming. It's hard to manage, sure to result in >>misinterpretation, and increases bureaucracy. > We have to keep it SIMPLE. That's why I like either the NO vote threshhold >(again, simple and easy to verify) or having a name czar (or better, a small >group of name czars just to prevent one person with an axe to grind from >making a big issue out of a single case). The NO vote threshhold, as has been pointed out repeatedly, suffers from the weakness of allowing a small group of people who disapprove of the *topic*, not the name, to block the creation of the group. Any mechanism that can be abused eventually will be. (I can see the memo now: "All AT&T employees WILL vote NO on comp.windows.motif!" [No slur of AT&T intended, of course.]) A committee structure will suffer from internal dissent, communication problems, rules of order, selection problems, and all the other ills that committees are prone to. I presume we all remember the issue that finally broke the Backbone Cabal? In all, a single name czar is probably the best solution. The trick will be pick someone who is acceptable to most people and is also stupid enough to take the job. This person must be reasonably well-connected, experienced, level-headed and able to deal with the inevitable abuse that will accompany the job. I am therefore announcing my candidacy for the position of Name Czar. I will post an article detailing my campaign platform as soon as I've come up with a good campaign slogan. Suggestions are welcome. Dave Mack Tomorrow's candidate today!
jmm@ecijmm.UUCP (John Macdonald) (10/26/89)
In article <1989Oct25.051238.4241@alembic.acs.com> csu@alembic.acs.com (Dave Mack) writes: >The NO vote threshhold, as has been pointed out repeatedly, suffers from >the weakness of allowing a small group of people who disapprove of the >*topic*, not the name, to block the creation of the group. Any mechanism >that can be abused eventually will be. (I can see the memo now: "All >AT&T employees WILL vote NO on comp.windows.motif!" [No slur of AT&T >intended, of course.]) I'm sure that this has also been countered repeatedly. Any group large enough to block a topic by the 100 NO rule is also large enough to block almost all topics by the current 100 excess yes over no rule. Only a small number of cases would be *changed* by adding the 100 NO vote rule. Of course, as we get continually larger voting turnouts, this will change. It is unlikely that any topic would get enough yes votes to outvote a (hypothetical) AT&T all-employee-no campaign under the current rules. (If such an event occurred there would be a flaming backlash against AT&T the likes of which we have never seen before - ** hypothetical immanent death of the net predicted ** :-) -- John Macdonald
csu@alembic.acs.com (Dave Mack) (10/27/89)
In article <903@ecijmm.UUCP> jmm@ecijmm.UUCP (John Macdonald) writes: >In article <1989Oct25.051238.4241@alembic.acs.com> > csu@alembic.acs.com (Dave Mack) writes: > >>The NO vote threshhold, as has been pointed out repeatedly, suffers from >>the weakness of allowing a small group of people who disapprove of the >>*topic*, not the name, to block the creation of the group. Any mechanism >>that can be abused eventually will be. (I can see the memo now: "All >>AT&T employees WILL vote NO on comp.windows.motif!" [No slur of AT&T >>intended, of course.]) > > >I'm sure that this has also been countered repeatedly. Any group large >enough to block a topic by the 100 NO rule is also large enough to >block almost all topics by the current 100 excess yes over no rule. >Only a small number of cases would be *changed* by adding the 100 NO >vote rule. Of course, as we get continually larger voting turnouts, >this will change. We have recently seen votes that had over 800 votes counted, and at least one recently which had over 100 NO votes and still passed. As the net grows, the number of voters will grow, making the 100-NO-vote rule increasingly unequitable and prone to abuse. The 100-NO-vote rule provides a mechanism for censorship on a net-wide basis. That wasn't what Peter Da Silva intended when he suggested it, I'm sure, but it could be used that way. It's a bad idea. Dave Mack
peter@ficc.uu.net (Peter da Silva) (10/27/89)
> The 100-NO-vote rule provides a mechanism for censorship on a net-wide > basis. That wasn't what Peter Da Silva intended when he suggested it, > I'm sure, but it could be used that way. It's a bad idea. Censorship? I think it's been hashed out often enough that not having a newsgroup does not constitute censorship. In any case, the 100 YES vote rule provides a mechanism for fraud on a net-wide basis. Percentage votes don't address the problem, they just up the ante a little. The only mechanisms for opposing this fraud that would have worked on recent votes are multi-way voting systems or the 100 no-vote rule. -- `-_-' Peter da Silva <peter@ficc.uu.net> <peter@sugar.hackercorp.com>. 'U` -------------- +1 713 274 5180. "That particular mistake will not be repeated. There are plenty of mistakes left that have not yet been used." -- Andy Tanenbaum (ast@cs.vu.nl)
dan@ccnysci.UUCP (Dan Schlitt) (11/01/89)
In article <4806@ncar.ucar.edu> woods@handies.UCAR.EDU (Greg Woods) writes: >In article <37123@looking.on.ca> brad@looking.on.ca (Brad Templeton) writes: >>All of the proposals share another major fault: complexity. >>Complexity breeds flaming. It's hard to manage, sure to result in >>misinterpretation, and increases bureaucracy. >> >>I firmly maintain the guidelines have to be made shorter, not longer. > > We have to keep it SIMPLE. That's why I like either the NO vote threshhold >(again, simple and easy to verify) or having a name czar (or better, a small >group of name czars just to prevent one person with an axe to grind from >making a big issue out of a single case). > I think that simplicity and verifiability are the most important things we >need in any new voting scheme. Flexibility of expression on the part of the >voters is nice, but not as important as keeping it simple and making it >easily verifiable. > >--Greg It has been a pleasure to watch the political idealism that has run through this thread. But idealism has its limits and Brad and Greg have hit upon two of the limits in the quoted material above. Recall if you will, that there have been vigorous complaints that the current system requires too much time to create a newsgroup and that the complex guidelines get in the way. I suggest that there are three things which are required of a useful and effective voting system. 1) It must be simple. 2) It must be verifiable. 3) It must give a definitive result. The present system, no matter what its other faults, satisfies these three requirements. I am yet to be convinced that the proposed changes, save the one introducing a "no vote" threshold, satisfy these three requirements. Introduction of a threshold for no votes that would prevent the creation of the newsgroup would be a significant change. It is really impossible to judge what it would do by looking at past votes. Under the present system it really doesn't make much difference if you vote against the creation of a group because a no vote can be offset by a yes vote. The introduction of the threshold significantly increases the value of a no vote. A simple threshold like 100 no votes means no number of yes votes can offset the no vote; Percentage thresholds are not quite so drastic in effect. The result will be that voter behavior will be radically changed from the past. It will pay to vote no and people will do so. It weights the scale against group creation (the intention of the proposers), but how heavily it does so is hard to evaluate. My guess is that it does so much more than its supporters intend. -- Dan Schlitt Manager, Science Division Computer Facility dan@sci.ccny.cuny.edu City College of New York dan@ccnysci.uucp New York, NY 10031 dan@ccnysci.bitnet (212)690-6868