macrev (12/12/82)
If the problem with poll-taking on the net is indeed the reluctance of readers to send mail, why not make it easier. It's easier to post an article than it is to send mail (my opinion). Why not create a newsgroup to be used solely for yes or no responses to net queries about adding or deleting news groups? This group (net.vote, for instance) could then be divided into subgroups that would identify the specific issue being voted on -- net.vote.trivia comes to mind immediately. Such a newsgroup would still not solve what seems to me to be a key problem in net polls -- how do you make sure that users who might have an interest in an issue know that a vote of some kind is being taken? One possibility: A message describing the issue could be posted as the first article in EVERY newsgroup for some specified period of time. The message could be very short, and it could direct yes or no responses to net.vote.wxyz. Readers would be advised that net.vote.wxyz would disappear after x days. I'm a new user, and I don't know very much about USENET administration. What I suggest may not be possible, or it may be asking too much of those who manage the net. Any comments?
sjb (12/13/82)
No, that's no good. The whole purpose of using mail is to take the 'yes/no' kind of votes OFF of USENET. A while back, everyone seemed to vote on things on the net. The result was hundreds of articles containing the single word 'yes' or 'no' loading down the net. People complained, and the new etiquette was modified to suggest that users use mail for such things rather than newsgroups. The problem with net.vote.whatever is that you are suggesting EVERY topic get its own subgroup! The net can't handle that many groups. Even if we were to expire them after a few days, a lot of people who don't get news until it's a few days old would just never see it in time (or never get it at all) If we stick to mail for responses and agree that dead groups should be removed if they aren't used, then that will result in much less overall traffic than net.vote.all
tihor (12/15/82)
#R:mhuxi:-3800:cmcl2:7900002:000:475 cmcl2!tihor Dec 14 16:36:00 1982 Actually the best solution, although given the current state of profusion of versions of news software it is probably infeasable, is to implement a separate news/notes option v as in vote which presented when a message has an appropriate header field/bit and which prompts for an appropriate response yes/no/don't care and 1-n should be sufficient choices and then mails a strictly formated message to the sender which could be tabulated by an appropriate piece of software.
george (12/20/82)
There have recently been some suggestions to add software for automating voting about various topics on the net. Installing software described in some of these suggestions would seem to be very detrimental to the communication load of the network. I have an alternate suggestion which would not be so extremely detrimental. I suspect that voting is not yet extensive enough to warrant any such special software to deal with it. Previous suggestions incorporated a menu of choices in a special article or group. The menu would presumably make voting very easy. The reader's vote would then be automatically mailed to the article's author. Presumably the alleged ease of use of menus would dramatically increase ratio of voters to readers. It might also dramatically increase the number of polls taken. The cost might tend to be proportional to the product of the ratio by the number of readers (of that group) by the average address length by the rate of such polls. The proposed method might increase the ratio from near zero to near unity. It might also increase the rate of such polls. It should also be noted that the body of the reply is probably small compared to the header and uucp overhead. My suggestion has nothing to do with menus. The suggestion involves a mechanism to batch the replies. Each poll would have a time, T, associated with it. T would be the sum of two other times. One of those, R, would be a the required time between an article being posted on a machine and its being read. The other time, M, would be the product of a distance, D, and the maximum time, N, to send mail from an arbitrary site to its neighbor. D would be the maximum distance (in nodes) from an arbitrary site to some collection site. For efficiency and timeliness the collection site should be a central node such as "decvax". For simplicity I shall consider the collection site to be the site of the author of the poll article. I would think that two days is a reasonable value for R, if weekends, holidays, and Usenix meetings are disregarded. I would hope that N is one day. The poll would be completed at time T after the posting time. This seems to be comparable or better than current manual polling times. Each instance of an article would have a deadline associated with it. At the originating site the deadline would be the posting time. When inews receives an article it would subtract N from the deadline. Inews might also set an expiration date based on the deadline. All votes on a particular machine would be collected until the deadline. Upon reaching the deadline, the votes would be sent to the neighbor site where the article was obtained. The neighbor would append those votes to its collection which would have approximately time N before its deadline is reached. T = R+M M = D*N The mail headers and uucp overhead should be substantially reduced. If a central node is used, the bodies will also be reduced. In reiteration, I suspect that voting is not yet extensive enough to warrant any such special software to deal with it. I did not want to see some poorly designed voting system implemented, which might overload the network. George Rosenberg duke!mcnc!idis!george decvax!idis!george