home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / news / groups / 24819 < prev    next >
Encoding:
Internet Message Format  |  1992-12-22  |  3.3 KB
  1. Xref: sparky news.groups:24819 news.admin.misc:881
  2. Newsgroups: news.groups,news.admin.misc
  3. Path: sparky!uunet!gatech!emory!nastar!phardie
  4. From: phardie@nastar.uucp (Pete Hardie)
  5. Subject: Re: PROPOSAL:  Yes votes >= 200+2*No Votes
  6. Message-ID: <1992Dec21.221311.17787@nastar.uucp>
  7. Organization: Digital Transmission Systems, Duluth, GA.
  8. References: <EMCGUIRE.92Dec12155241@mother.intellection.com> <BzBMAn.57y@rice.edu> <EMCGUIRE.92Dec17092630@fuller.intellection.com>
  9. Date: Mon, 21 Dec 1992 22:13:11 GMT
  10. Lines: 63
  11.  
  12. In article <EMCGUIRE.92Dec17092630@fuller.intellection.com> emcguire@intellection.com (Ed McGuire) writes:
  13. >I think the way to avoid this is to agree in advance on some objective
  14. >metrics.  I'm unsure what metrics to use, but there are some numbers
  15. >floating around which /may/ fit the bill.
  16. >
  17. >For example, the UUNET news statistics include the number of sites
  18. >where at least one person posted an article within the last two weeks
  19. >(25821 in the December 9 article).  It's not so important that we have
  20. >an accurate count of netnews sites as that we have a factor in the
  21. >voting rule which reflects the growth of netnews.  The question
  22. >remaining is what constant multiplier should be used with 25821 as a
  23. >coefficient.  And I would expect that the average over a three or six
  24. >month period would be more reliable than just using the most recent
  25. >figure.
  26.  
  27. I like this idea.
  28.  
  29. However, playing Devil's Advocate for a moment, I see some objections that
  30. might come up:
  31.  
  32. 1) This places power into the hands of UUNET, at least in that whoever it is
  33. in that organization reporting the statistics can skew them, in theory.
  34.  
  35. 2) This places a single 'point of failure' at UUNET.  Should UUNET get wiped 
  36. off the face of the planet, how do we get the numbers for the next vote(s)?
  37.  
  38. 3) UUNET is not 'central' enough for regional hierarchies, and non-USA
  39. hierarchies.
  40.  
  41. Now I can counter some of these points immediately:
  42.  
  43. 1) It should be possible to have the large sites UUNET feeds compile the same
  44. lists, and merge them for the same result, at least for the accuracy this
  45. idea needs, alleviating the problem of one person/small group skewing the
  46. net growth.
  47.  
  48. 2) Similarly, the backbone sites can run the same compilation, and we can
  49. agree on an 'order of succession' should any one major site get removed.
  50.  
  51. 3) Perhaps the regional hierarchies can set up similar sites for their own
  52. subnet traffic.  I believe the European sites tend to feed through single
  53. sites in many countries, facilitating the collection of statistics.  However,
  54. the debates I've seen of the control issues make those sites more likely to
  55. fall into item number (1) above
  56.  
  57. >I agree that "traffic on this topic" is difficult to formalize and may
  58. >lead to flame wars.  On the other hand, we don't know in advance until
  59. >it is tried.  It is certainly possible to count articles in related
  60. >mailing lists and to estimate percent of traffic in existing groups,
  61. >and it would be up to the proponents of the new group to come up with
  62. >a consensus figure during the CFD period.
  63.  
  64. For the rec,games.frp spilt, there were a good number of topic counts used to
  65. justify the split into various subgroups based on traffic, so this can be
  66. done.
  67.  
  68.  
  69.  
  70. -- 
  71. Pete Hardie:  phardie@nastar  (voice) (404) 497-0101
  72. Digital Transmission Systems, Inc., Duluth GA
  73. Member, DTS Dart Team           |  cat * | egrep -v "signature virus|infection" 
  74. Position:  Goalie               |
  75.