brad@looking.on.ca (Brad Templeton) (09/20/89)
In order to find out just how successful groups created under the guidelines
have been, I decided to look up the readership stats for all groups that
were not on Brian's readership guidelines near the end of 1987.
The results follow. Almost one group has been created per week. Yet
only 8 groups created in the 'official' way have managed to get at least one
reader per machine they propagate to! Only 2 (plus comp.binaries.ibm.pc.d,
which I am unsure of) made the top 50. The vast majority are going to large
numbers of machines where nobody reads them at all. (While Brian's numbers
are not super-accurate, they are reliable for readers per machine, as the
net size estimate is not figured in. If anything, since he surveys big
machines, this figures are even more embarrasing)
Notes on the top groups
(*) Alt group created on whim
(F) Created by Fiat
(?) Wasn't there something special about the creation of this?
(+) Created by survey after immensely popular alt group.
7 49000 2285 66% 601 1260.0 11% 0.03 9.8% alt.sex(*)
10 40000 1872 98% 1 4.7 0% 0.00 8.0% news.announce.newusers(F)
28 28000 1327 86% 700 1053.2 10% 0.06 5.7% misc.consumers
38 24000 1133 94% 278 440.8 5% 0.03 4.9% comp.binaries.ibm.pc.d(?)
39 24000 1117 53% 32 152.6 13% 0.01 4.8% news.announce.newgroups
40 24000 1106 51% 268 545.8 2% 0.02 4.7% alt.sex.bondage(*)
59 20000 953 95% 12 408.0 0% 0.04 4.1% comp.sources.x
68 19000 902 96% 695 1286.4 5% 0.12 3.9% comp.sys.mac.programmer
69 19000 898 95% 337 562.3 0% 0.05 3.8% comp.sys.next(F)
72 19000 886 96% 85 171.2 10% 0.02 3.8% comp.sources.games.bugs
76 18000 860 92% 355 571.5 11% 0.05 3.7% comp.unix.i386
77 18000 850 82% 75 195.1 6% 0.02 3.6% sci.physics.fusion(+)
102 15000 723 89% 231 301.2 9% 0.03 3.1% rec.music.cd
My conclusion? Of all the groups created in almost the last couple of years,
only misc.consumers and a couple of special comp groups can be claimed to
be any sort of success. But even more interesting is the fact that in
spite of all the usenet-bureaucrats, almost as many groups created
against the guidelines have enjoyed high readership and success.
It will come as no surprise to anybody that I give the guidelines a D+ in
this report card, but I have some stats to back it up in this posting.
----- Less than one reader per machine ----- (propagation not counted)
(26 more guildline-created groups rate between .5 and 1 readers/machine)
109 15000 707 58% 364 563.4 4% 0.04 3.0% news.newusers.questions
110 15000 699 87% 348 923.9 10% 0.10 3.0% sci.environment
111 15000 688 94% 423 832.0 3% 0.09 2.9% comp.sys.amiga.tech
112 14000 679 87% 102 163.6 0% 0.02 2.9% comp.virus
115 14000 673 97% 114 202.5 7% 0.03 2.9% comp.std.c
118 14000 665 95% 38 77.0 0% 0.01 2.8% comp.parallel
127 13000 619 90% 4 169.4 0% 0.02 2.7% comp.sources.sun
130 13000 613 58% 27 37.1 4% 0.00 2.6% alt.sources.d
135 13000 600 94% 49 93.4 17% 0.01 2.6% comp.protocols.nfs
140 12000 580 96% 4 6.3 50% 0.00 2.5% comp.windows.misc
143 12000 571 96% 33 56.7 16% 0.01 2.4% comp.mail.sendmail
149 12000 565 83% 435 723.7 2% 0.09 2.4% rec.backcountry
150 12000 561 71% 153 375.3 0% 0.04 2.4% soc.couples
154 12000 559 95% 46 98.4 23% 0.01 2.4% comp.fonts
155 12000 554 76% 152 581.4 18% 0.07 2.4% gnu.emacs
159 12000 546 86% 20 27.8 0% 0.00 2.3% comp.realtime
161 11000 538 89% 156 304.0 0% 0.04 2.3% sci.military
164 11000 534 95% 58 88.8 7% 0.01 2.3% comp.unix.aux
167 11000 523 92% 30 56.5 4% 0.01 2.2% comp.lang.eiffel
169 11000 517 70% 175 264.1 13% 0.03 2.2% alt.rock-n-roll
174 11000 513 61% 155 484.4 9% 0.05 2.2% alt.activism
176 11000 508 95% 2 3.7 0% 0.00 2.2% comp.archives
186 10000 486 81% 152 305.1 5% 0.04 2.1% rec.autos.sport
193 10000 474 82% 20 55.6 5% 0.01 2.0% comp.sw.components
194 10000 474 66% 63 143.5 8% 0.02 2.0% alt.bbs
196 10000 471 91% 5 24.4 0% 0.00 2.0% comp.org.ieee
200 10000 469 93% 81 109.7 7% 0.02 2.0% comp.windows.ms
202 9800 461 58% 63 96.8 12% 0.01 2.0% alt.msdos.programmer
206 9400 442 77% 55 69.8 6% 0.01 1.9% gnu.gcc
210 9100 430 93% 36 108.6 0% 0.02 1.8% sci.nanotech
211 9100 430 59% 54 89.9 31% 0.01 1.8% alt.restaurants
216 8900 417 67% 145 202.5 12% 0.03 1.8% alt.cult-movies
224 8500 399 82% 58 154.8 4% 0.03 1.7% sci.edu
230 8100 380 64% 237 486.6 12% 0.07 1.6% sci.energy
233 7800 365 93% 103 159.6 9% 0.03 1.6% rec.music.bluenote
235 7800 365 77% 85 787.6 3% 0.14 1.6% gnu.gcc.bug
238 7700 362 93% 12 25.0 33% 0.01 1.6% sci.logic
240 7700 361 80% 53 91.6 4% 0.02 1.5% gnu.g++
------ Less than one reader for every 2 machines -----
244 7600 358 70% 51 83.9 25% 0.01 1.5% alt.fax
249 7500 355 72% 301 654.3 7% 0.11 1.5% soc.culture.asian.american
251 7400 350 76% 86 128.5 15% 0.02 1.5% rec.music.newage
255 7300 342 46% 127 220.3 1% 0.03 1.5% gnu.misc.discuss
257 7200 339 44% 113 196.3 0% 0.02 1.5% alt.romance
259 7200 338 83% 24 32.6 4% 0.01 1.4% sci.chem
265 6800 318 85% 98 281.2 38% 0.06 1.4% rec.arts.misc
276 6400 302 82% 38 44.5 28% 0.01 1.3% rec.ham-radio.swap
278 6400 299 88% 72 172.0 21% 0.04 1.3% soc.culture.arabic
286 6200 290 79% 42 85.9 0% 0.02 1.2% comp.sys.super
289 6000 284 88% 13 15.8 0% 0.00 1.2% comp.protocols.iso.dev-environ
290 6000 281 87% 7 12.5 0% 0.00 1.2% comp.lsi.cad
291 6000 281 74% 6 6.7 0% 0.00 1.2% gnu.config
292 5900 278 63% 9 28.8 0% 0.01 1.2% soc.feminism
294 5800 275 75% 63 151.5 0% 0.04 1.2% gnu.emacs.bug
297 5800 272 58% 46 55.5 5% 0.01 1.2% comp.sys.mips
299 5700 268 88% 3 3.8 0% 0.00 1.1% comp.ai.shells
301 5700 266 85% 160 231.3 1% 0.06 1.1% rec.music.dementia
304 5400 253 74% 58 155.0 2% 0.04 1.1% gnu.utils.bug
306 5300 250 57% 215 276.4 4% 0.05 1.1% rec.arts.tv.uk
310 5100 242 89% 61 135.1 2% 0.04 1.0% comp.mail.mush
311 5100 242 74% 21 39.3 0% 0.01 1.0% sci.med.physics
313 5100 240 89% 13 10.4 0% 0.00 1.0% comp.protocols.kerberos
314 5100 240 46% 103 146.6 2% 0.02 1.0% alt.religion.computers
--- Less than one reader for every 3 machines --- (and so on)
316 5100 239 38% 40 74.2 16% 0.01 1.0% comp.os.mach
320 4900 230 94% 2 3.8 0% 0.00 1.0% comp.org.usrgroup
323 4900 230 52% 195 916.5 0% 0.18 1.0% misc.headlines.unitex
325 4800 226 82% 10 21.8 10% 0.01 1.0% comp.lang.lisp.x
327 4700 223 95% 4 32.9 0% 0.01 1.0% comp.simulation
330 4700 220 73% 23 40.9 0% 0.01 0.9% gnu.emacs.gnus
331 4700 220 47% 473 812.1 1% 0.15 0.9% soc.culture.hongkong
334 4600 217 82% 23 39.0 0% 0.01 0.9% comp.soft-sys.andrew
338 4600 216 68% 19 38.7 6% 0.01 0.9% alt.emusic
340 4500 213 65% 61 254.0 0% 0.07 0.9% news.software.anu-news
341 4500 211 47% 50 112.6 4% 0.02 0.9% talk.rape
342 4500 210 73% 8 7.2 38% 0.00 0.9% gnu.chess
349 4300 201 67% 115 236.8 10% 0.07 0.9% alt.individualism
350 4300 200 65% 249 653.6 15% 0.18 0.9% talk.politics.guns
352 4200 199 63% 126 201.6 9% 0.05 0.9% alt.fishing
353 4200 197 74% 26 65.8 4% 0.02 0.8% gnu.gdb.bug
354 4200 197 36% 182 359.6 9% 0.06 0.8% alt.gambling
356 4200 196 78% 11 59.2 9% 0.02 0.8% sci.philosophy.meta
358 4100 192 67% 354 890.1 0% 0.26 0.8% alt.sca
360 4000 189 83% 19 20.7 0% 0.01 0.8% comp.protocols.iso.x400
361 4000 189 65% 136 312.9 1% 0.09 0.8% alt.recovery
362 4000 188 85% 5 8.3 0% 0.00 0.8% comp.mail.multi-media
363 4000 187 74% 103 312.1 2% 0.10 0.8% gnu.g++.bug
364 4000 186 60% 365 660.4 4% 0.18 0.8% soc.culture.nordic
366 3900 183 78% 15 23.6 0% 0.01 0.8% talk.politics.soviet
368 3800 180 81% 56 102.4 8% 0.04 0.8% rec.folk-dancing
369 3700 173 88% 12 43.9 0% 0.02 0.7% comp.lang.scheme.c
372 3600 170 91% 20 430.3 0% 0.20 0.7% comp.binaries.apple2
377 3500 165 64% 111 176.7 0% 0.06 0.7% gnu.bash.bug
378 3500 165 64% 12 79.7 8% 0.03 0.7% alt.prose
380 3500 163 57% 13 29.1 15% 0.01 0.7% bionet.general
382 3400 161 80% 10 30.2 0% 0.01 0.7% comp.sys.isis
383 3400 160 74% 5 3.0 0% 0.00 0.7% gnu.test
384 3400 158 70% 18 49.2 12% 0.02 0.7% gnu.g++.lib.bug
390 3200 151 75% 1 1.3 0% 0.00 0.6% comp.lang.visual
392 3100 148 72% 12 15.8 0% 0.01 0.6% gnu.ghostscript.bug
395 3100 146 30% 60 126.3 0% 0.02 0.6% misc.emerg-services
396 3000 141 74% 16 15.8 13% 0.01 0.6% gnu.emacs.vms
397 3000 141 61% 5 5.5 0% 0.00 0.6% gnu.emacs.gnews
400 2800 134 90% 9 17.4 0% 0.01 0.6% soc.politics
401 2800 134 80% 84 466.1 25% 0.24 0.6% soc.culture.turkish
402 2800 133 56% 4 3.8 0% 0.00 0.6% alt.california
404 2700 127 56% 11 16.8 0% 0.01 0.5% bionet.jobs
405 2600 124 45% 230 451.9 0% 0.14 0.5% rec.music.dylan
408 2500 117 58% 3 3.5 0% 0.00 0.5% alt.postmodern
409 2400 113 76% 9 13.9 11% 0.01 0.5% comp.os.aos
410 2400 111 85% 10 19.9 0% 0.01 0.5% comp.sys.ti.explorer
413 2100 100 11% 155 276.3 55% 0.03 0.4% unix-pc.general
414 2100 99 53% 27 41.1 0% 0.02 0.4% alt.co-ops
415 1900 89 84% 2 2.9 0% 0.00 0.4% comp.protocols.iso.x400.gateway
416 1900 88 84% 4 6.2 50% 0.00 0.4% comp.os.rsts
417 1900 88 4% 38 64.6 3% 0.00 0.4% sci.skeptic
418 1800 86 59% 61 115.7 7% 0.07 0.4% alt.prose.d
419 1700 81 10% 11 428.9 100% 0.05 0.3% unix-pc.sources
421 1700 79 10% 92 174.7 3% 0.02 0.3% soc.rights.human
422 1600 76 40% 292 418.9 0% 0.19 0.3% alt.cosuard
423 1600 75 46% 10 16.3 0% 0.01 0.3% bionet.software
426 1500 71 94% 2 2.3 50% 0.00 0.3% comp.sys.ridge
428 1400 65 5% 2 7.7 50% 0.00 0.3% sci.aeronautics
430 1300 60 56% 5 3.3 0% 0.00 0.3% bionet.molbio.gene-org
431 1100 54 10% 2 2.0 0% 0.00 0.2% unix-pc.bugs
432 1000 49 56% 2 1.1 0% 0.00 0.2% bionet.molbio.news
433 1000 49 10% 8 11.9 0% 0.00 0.2% unix-pc.uucp
434 1000 47 46% 10 166.3 0% 0.14 0.2% bionet.journals.contents
435 940 44 56% 1 1.4 100% 0.00 0.2% bionet.molbio.embldatabank
436 910 43 27% 4 2.2 0% 0.00 0.2% bionet.agroforestry
437 790 37 56% 1 5.8 0% 0.01 0.2% bionet.molbio.evolution
438 700 33 56% 2 1.5 0% 0.00 0.1% bionet.molbio.methds-reagnts
439 640 30 9% 8 11.0 0% 0.00 0.1% unix-pc.test
440 620 29 5% 21 40.3 0% 0.01 0.1% soc.rights.alien
442 450 21 6% 3 6.0 100% 0.00 0.1% u3b.tech
--
Brad Templeton, Looking Glass Software Ltd. -- Waterloo, Ontario 519/884-7473tale@pawl.rpi.edu (David C Lawrence) (09/20/89)
None of the alternate hierarchies should even be included in Brad's
report card, since you claim it addresses the group creation
guidelines. That drops the size of the article considerably. Yes,
there are still other aspects of his analysis that have merit, yet
including gnu, alt, bionet, unix-pc, u3b and the inet groups is simply
misleading.
--
(setq mail '("tale@pawl.rpi.edu" "tale@itsgw.rpi.edu" "tale@rpitsmts.bitnet"))cosell@bbn.com (Bernie Cosell) (09/20/89)
In article <1989Sep20.060201.4473@rpi.edu> tale@pawl.rpi.edu (David C Lawrence) writes: }None of the alternate hierarchies should even be included in Brad's }report card, since you claim it addresses the group creation }guidelines. I disagree. The hypothesis under consideration is whether the guidelines we follow in fact have any merit: if they act as a filter to improve the quality, popularity, etc, of the groups that succeed in running their gauntlet. The problem with testing this hypothesis SOLELY on the main-hierarchy newsgroups is that there is no way to measure the *effect* of the guidelines. However, if we contrast the mainline hierarchy against, say, the alt hierarchy, we can SEE if the guidelines make any apparent difference. I agree that one should be careful about "per machine" stats for the main hierarchy: LOTS of sites carry *all* of the 'approved' newsgroups, and so mainline newsgroups will surely have more trouble getting the same 'average' (just as once you distribute a formerly 'club' magaznie nationally, dividing by the new "potential circulation" is hopeless). But that also cuts the other way, of course: LOTS more people have the easy-opportunity to read and post to the new groups. So while I think you have to be judicious about what stats you use and how you weigh them, comparing the new-newsgroup profiles between the hierarchies seems pretty reasonable to me. /Bernie\
wbt@cbnews.ATT.COM (William B. Thacker) (09/20/89)
In article <17735@looking.on.ca> brad@looking.on.ca (Brad Templeton) writes: >In order to find out just how successful groups created under the guidelines >have been, I decided to look up the readership stats for all groups that >were not on Brian's readership guidelines near the end of 1987. > >The results follow. Almost one group has been created per week. Yet >only 8 groups created in the 'official' way have managed to get at least one >reader per machine they propagate to! Only 2 (plus comp.binaries.ibm.pc.d, >which I am unsure of) made the top 50. The vast majority are going to large >numbers of machines where nobody reads them at all. While this at one point appears a reasonable measurement, I find it quite unreasonable. It seems somehow odd to discount a newsgroup of 15,000 readers (400-500 bonafide) with the wave of a hand because "that's less than one reader per machine". From the immediate, self-centered viewpoint, it does make sense to do so (*not* intending to flame here; couldn't think of a more polite way to word it). After all, as administrator on Site X, "why carry comp.fubar if none of my readers read it ? On the other hand, I *do* want to carry comp.snafu, as I read that myself." But what needs be considered, I feel, is that at the next site downstream, the adminstration is wondering, "Why carry comp.snafu? Nobody here reads it. I'm only interested in comp.fubar." It seems to me that this is all part of the cost of being in a net; you carry other peoples' groups, for the sake of their connectivity, and they carry yours. Even the most popular groups have only 3-4 readers per site, if my memory serves (naturally, the monthly arbitron posting has expired here...). I seem to recall 60,000 for r.h.f. Clearly, by any standards, some groups will be held more popular than others. Rec.humor.funny is a clear example; always near the top of the readership list, low in volume, virtually zero cost per reader. On the other hand, it serves only for entertainment, so I suppose some would claim it's not a "good" newsgroup, either. But to hold all newsgroups against that sort of standard is, IMHO, ridiculous. The most effective standard by which I would summarily judge a group is the traffic per reader figure; and I hesitate even to apply that. Quite simply, if every group had a readership in excess of 30,000 (two per machine), I contend that the volume in those groups would become so unmanageable that public referendum (survey, if you insist) would soon split them into smaller groups, with less than 15,000 readers each. We see this happening even now; witness the creation of talk.politics.guns from the overcrowded talk.politics.misc. Anyway, Brad, my curiousity is piqued. Having implied the majority of the newsgroups created in the past two years are failures, what criteria would you suggest as adequate demonstration of a group's worth ? - - - - - - - - valuable coupon - - - - - - - clip and save - - - - - - - - Bill Thacker wbt@cbnews.att.com I have short-term memory loss, though I like to think of it as Presidential eligibility. - Paula Poundstone, NNTN
woods@ncar.ucar.edu (Greg Woods) (09/20/89)
In article <45814@bbn.COM> cosell@BBN.COM (Bernie Cosell) writes: >The hypothesis under consideration is whether the >guidelines we follow in fact have any merit: if they act as a filter to >improve the quality, popularity, etc, of the groups that succeed in >running their gauntlet. Just for the record, the purpose of the guidelines is not to be a filter for newsgroup quality. It is to reduce flame wars over group creations. Therefore Brad's statistics judging the guidelines based on the readership of created groups are a red herring. Brad also conveniently forgets to mention that several of the "successful" groups he mentions (sci.physics.fusion, comp.sys.next) had their creations accompanied by massive flame wars. If one wants to argue that having the guidelines is a bad idea, one will have to accept the resulting flame wars (and possibly rmgroup wars) that would result without them. Secondly, I do not trust the readership per machine statistics that Brad is using. The reason is NNTP, with which arbitron does not work well. Our site is a good example. We probably have about 100 readers of news here. If I run arbitron on the "ncar" machine, where all articles are posted from, it will show about 3. The reason is that the vast majority of our newsreaders here read news remotely via rrn and NNTP. Aside from the fact that lack of history and/or active files on those machines makes running arbitron on them impossible, even if the script were modified to fetch the active file remotely, to get statistics for our site would require running arbitron on over 20 machines here. Most of these machines are not under my control, so even if I *wanted* to take the time required to install and run arbitron on 20+ machines, I lack the necessary access to them to do so. Yes, I could cajole the admins of those machines into doing it (maybe), but now you're talking a LOT of work! It's simply too much of a hassle. Why is all of this important? Because I suspect that most medium to large sites are using this method now for distributing news to their users. Surely I am not the only one that finds the prospect of having to install and run arbitron on this many machines to get accurate statistics to be too time consuming. This means that the number of readers per machine/site (which is the stat that Brad is using) may well be underestimated. Either that or these sites are not being represented adequately. I also think that the number of machines on the whole net, and therefore the number of total readers, is OVERestimated, but I don't have any hard evidence for that. --Greg
brad@looking.on.ca (Brad Templeton) (09/21/89)
No, the alternate groups are the whole point of the report card! How could I delete them? I wanted to compare the success and popularity of groups created in the guidelines way with groups created in alternate ways. I think our goal in choosing a group creation mechanism is to pick groups which will be used and appreciated by the readers (not the posters) of the net. The report card provides statistics on how we have done compared to other creation mechanisms. -- Brad Templeton, Looking Glass Software Ltd. -- Waterloo, Ontario 519/884-7473
ray@philmtl.philips.ca (Raymond Dunn) (09/21/89)
In article <17735@looking.on.ca> brad@looking.on.ca (Brad Templeton) writes: > >My conclusion? Of all the groups created in almost the last couple of years, >only misc.consumers and a couple of special comp groups can be claimed to >be any sort of success. Equating "success" with the number of readers per machine is, I suppose, appropriate on Clarinet. I doubt whether a majority of the many readers in the sum of the low readership USENET groups would agree. Some of the groups that I look forward to reading most fall into this "unsuccessful" criteria. >It will come as no surprise to anybody that I give the guidelines a D+ in >this report card, but I have some stats to back it up in this posting. Which only proves once again, that stats can be twisted to prove any argument, no matter how unfounded. -- Ray Dunn. | UUCP: ray@philmt.philips.ca Philips Electronics Ltd. | ..!{uunet|philapd|philabs}!philmtl!ray 600 Dr Frederik Philips Blvd | TEL : (514) 744-8200 Ext : 2347 (Phonemail) St Laurent. Quebec. H4M 2S9 | FAX : (514) 744-6455 TLX : 05-824090
brad@looking.on.ca (Brad Templeton) (09/21/89)
Greg has often written to me that he doesn't feel there is any significant accuracy to the readers/machine figures that one can derive from Brian's arbitron figures. One thing is clear, the readers/machine figure is exact for arbitron sites. Does that relate to the whole net? Greg thinks no, because at his site they have an NNTP server where nobody reads news and lots of clients which are never counted in arbitron surveys. Is this typical? I also know sites which have a server where lots of people read news on the server, and others read on the clients. Which is more common? But I fail to see why this is a problem. Are many arbitron reports sent in for servers with no readers? Why would anybody bother so send in such a report? Arbitron senders, let me know? If anything, arbitron is highly biased to large sites, which would mean that the figure of readers/machine on arbitron sites is higher than the figure for the net. For it to be lower, arbitron would have to be stronly biased towards small sites and sites without a lot of newsreaders. I have a hard time understanding how this could be. In fact, isn't the whole point of NNTP to allow newsreading on small machines? So not having them included in the arbitron stats would only increase the readers/machine figure. The real figure we want is total readers per 'thing that costs money,' namely long disk storage and long distance transmission. But that's harder to figure out. -- Brad Templeton, Looking Glass Software Ltd. -- Waterloo, Ontario 519/884-7473
brad@looking.on.ca (Brad Templeton) (09/21/89)
In article <4402@ncar.ucar.edu> woods@handies.UCAR.EDU (Greg Woods) writes: > Just for the record, the purpose of the guidelines is not to be a filter >for newsgroup quality. It is to reduce flame wars over group creations. Yes and no. I could reduce the flame wars pretty easily by rmgrouping news.groups or any other place they take place, but would that be a good solution. Removing the flame wars is very important, but if our method does a lousy job of picking groups, then aren't we a bit off the mark? >that several of the "successful" groups he mentions (sci.physics.fusion, >comp.sys.next) had their creations accompanied by massive flame wars. The flame wars were caused by the guidelines. I dunno about you, but I saw immediate need for sci.physics.fusion and I was hardly alone. What annoyed people was that it took so long to create the group that the biggest debate in the last 2 decades of science had all but fizzed out by the time the group got created? The 'success' story was alt.fusion, created in frustration, and immediately one of the top net groups from the moment of creation. Sci.physics.fusion is the remnant of that. -- Brad Templeton, Looking Glass Software Ltd. -- Waterloo, Ontario 519/884-7473
lmb7421@ultb.UUCP (L.M. Barstow) (09/21/89)
After debating what to say about the article Brad just posted (I'm not
going to post any of it again...the readable part has already been
re-posted numerous times, and the other part isn't worth it)
I decided that I'd simply say one (okay, maybe two) things:
one: The stats were great, Brad. However, it would be nice if you took
into consideration the importance of the groups you listed in
addition to the number of people who use it, the fact that those
stats are probably wildly off (I know our machine certainly proves
them wrong), and the fact that, despite the "low" number of users,
thre are still more than enough readers to justify a newsgroup.
two: The newsgroups that passed, passed. This means that a poll of the
net came up with enough support and not enough objection that the
group was created...Like it or not, people wanted these groups.
What's your beef against the creation policy, Brad? Someone had to make
up something...What we've got is likely to be the best we'll have for a
while. Your suggestions (the ones I've seen to date) aren't the
solution. Live with it...don't rip away your supports unless and until
you have a new support built to take the load.
--
Les Barstow |Bitnet: LMB7421@RITVAX
"What about the R.O.U.S's?" |UUCP: ...rutgers!rochester!ritcv!ultb!lmb7421
"The Rodents Of Unusual Size? |ARPA: lmb7421@ultb.isc.rit.edu
I don't believe they exist!" - Buttercup and Wesley, _The Princess Bride_brad@looking.on.ca (Brad Templeton) (09/21/89)
I'm not saying it's a perfect criterion, just one of the few semi-objective criteria that we have available. Yes, I think many low-readership groups have merit, and I read some. But what we're after here is a method to decide what groups to create on almost *all* machines. Now if a group isn't even going to have any readers on 2/3 of the machines on the net, one can argue that it is not a good group to carry on all machines. Still a good group to carry on some, no doubt. Yes, sometimes you carry a group your machine doesn't want, but there is a limit to that. Why else do the 'vote'/surveys try to guage 'interest' in a group, if not to answer a criterion like the above? -- Brad Templeton, Looking Glass Software Ltd. -- Waterloo, Ontario 519/884-7473
ambar@ora.ora.com (Jean Marie Diaz) (09/23/89)
In article <18401@looking.on.ca> brad@looking.on.ca (Brad Templeton) writes: >In fact, isn't the whole point of NNTP to allow newsreading on small machines? >So not having them included in the arbitron stats would only increase the >readers/machine figure. No, the "point" of NNTP (insamuch as NNTP relates to newsreading -- that T stands for Transmission, ya know) is to get rid of small machines at large installations. Before all the admins of one- or two-person machines get out their flamethrowers, let me explain what I mean, using MIT as an example. Before NNTP, MIT had hundreds of Unix boxes (little and not-so-little) hanging around campus. If someone on one of those boxes wanted to read Usenet, they had to a) install it themselves, on their own machine, b) beg their system administrator to install it, or c) beg for a guest account on one of the machines who did. Enter NNTP. Now, MIT still has hundreds of Unix boxes, but no one on campus has to install all of netnews on their system in order to read news. If they send mail to usenet@bloom-beacon.mit.edu, we will tell them where to pick up the rn sources. If they are in the .media, .ai, or .lcs subdomains, there is already a "main news machine" in their laboratory for them to use. Otherwise, they read news off of bloom-beacon. Everyone is happy; there are fewer news machines at MIT; and bloom-beacon has an average load of 8 :-) However, since the news administrators only control the news machine, and not the client machines where .newsrc files live, we can't run arbitron. It's also very difficult (but not impossible) to run arbitron over a multi-machine news system even when the same person administrates both news and the systems as a whole. I had this problem at Oracle -- there weren't enough hours in my day to hack arbitron to run on thirty different machines and consolidate things into one report. What I'm arguing is that, in any news system that has more than one machine (even one as small as ORA, which has three machines on one ethernet), NNTP will probably be in use. In any system where NNTP is in use, running arbitron is very difficult. Therefore, arbitron's numbers are biased towards one-machine news systems. (Followups are set to news.misc.) AMBAR ambar@ora.com uunet!ora!ambar
peter@ficc.uu.net (Peter da Silva) (09/24/89)
In article <17735@looking.on.ca>, brad@looking.on.ca (Brad Templeton) writes: > In order to find out just how successful groups created under the guidelines > have been, I decided to look up the readership stats for all groups that > were not on Brian's readership guidelines near the end of 1987. Since the guidelines haven't been around that long, that's rather unfair. comp.unix.i386 has been a sucessful group. It would not have been created under your alternate guidelines. -- Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation. Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-' "That is not the Usenet tradition, but it's a solidly-entrenched U delusion now." -- brian@ucsd.Edu (Brian Kantor)
peter@ficc.uu.net (Peter da Silva) (09/24/89)
In article <155@ora.ora.com>, ambar@ora.ora.com (Jean Marie Diaz) writes: > What I'm arguing is that, in any news system that has more than one machine > NNTP will probably be in use. Hmmm... interesting. Why aren't there more people using remote file systems of one sort or another? We have some 30 machines here with a very stateful remote file system called OpenNET. Almost full UNIX semantics on the remote machine. We just run vnews with the paths to the sys and spool directories pointing to the machine with the news on it. -- Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation. Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-' "That is not the Usenet tradition, but it's a solidly-entrenched U delusion now." -- brian@ucsd.Edu (Brian Kantor)
oliver@unc.cs.unc.edu (Bill Oliver) (09/26/89)
In article <18401@looking.on.ca> brad@looking.on.ca (Brad Templeton) writes: > >The real figure we want is total readers per 'thing that costs money,' >namely long disk storage and long distance transmission. But that's harder >to figure out. I think that some of these low-readership or low-posting groups are saving resources because their existence decreases traffic to higher-readership groups. For example, in olden time, about every six months or so somebody in soc.women would write in and call for a boycott of male posters, or some modification of that call. There would ensue a good deal of posting and flaming regarding who should or should not be posting and how folk are nice or not nice posters, etc. I have not seen that call for a while, and I think that some of it is due to the existence of soc.feminism -- a nice, moderated place where people are supposed to be polite and socially acceptable. As far as I'm concerned, the primary value of soc.feminism is its effect on soc.women. I'll bet there is quite a net savings in bandwidth even if few people post to or read the group. Bill Oliver