[news.misc] Report Card on the success of the group creation guidelines

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-7473

tale@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