Xref: utzoo news.groups:8487 news.admin:5289
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!apple!chuq
From: chuq@Apple.COM (Chuq Von Rospach)
Newsgroups: news.groups,news.admin
Subject: Re: Proposed OFFICIAL Newsgroup Creation/Deletion Guidelines
Message-ID: <27934@apple.Apple.COM>
Date: 27 Mar 89 19:33:20 GMT
References: <37740@bbn.COM> <27806@apple.Apple.COM> <5134@cbnews.ATT.COM> <27870@apple.Apple.COM> <11346@s.ms.uky.edu>
Organization: Life is just a Fantasy novel played for keeps
Lines: 53

>Chuqui -- how 'bout:

>6) You don't want an overly simple namespace.  The reasons you don't
>want an overly simple namespace are twofold:
>a) The naive user with his/her myriad of questions keeps finding
>   one place to post questions to when the questions are really on
>   many topics.  This raises volume in each group needlessly.
>b) Splitting traffic flow over a smaller number of groups makes
>   it easier for individual postings to be lost in the shuffle.

Nope. You don't want it overly simple. You want it efficient. I'm arguing
for efficient, not simple. To explain the difference, look at theoretical
ideals for the two:

o simple: the ideal simple network structure is a single large group. That
  way you never have cross-posted or incorrectly posted messages.

o efficient: an ideal efficient name space means that every posting has a 
  single, optimal newsgroup for posting and that there are no newsgroups
  that have no traffic. Everything gets used, and everything that's needed
  is there.

Obviously, because the net is a constantly mutating beast, the ideal will
never be met. But my feeling is that we can do some judicious pruning to
make the net more efficient and reduce name-space confusion without doing
major surgery or causing problems. In fact, if you take my definition at
face value, a pruning that causes problems reduces efficiency and is
therefore wrong. 

If I were for simplicity for simplicity sake, I wouldn't have been the
person who fostered both comp.sys.mac.programmer and comp.sys.mac.hypercard.
That doesn't increase simplicity. I do feel, however, that the groups
increase efficiency -- because, "just say 'n' fanatics" to the contrary,
there is a limit to the amount of volume you can wedge in a group before the
group starts to collapse in onto itself because of the noise.

>Oh yeah, small number of groups doesn't necessarily mean a simple
>namespace, and neither does a large number of groups mean a complex one.
>But they tend to follow from each other.

Nope. You're right again. You don't create groups for the sake of creating,
you don't trim for the sake of trimming. (inspired readers will notice that
I'm not giving recommendations of group names that I'd recommend for pruning
under this proposal. This is not accidental).


Chuq Von Rospach       -*-      Editor,OtherRealms      -*-      Member SFWA
chuq@apple.com  -*-  CI$: 73317,635  -*-  Delphi: CHUQ  -*-  Applelink: CHUQ
      [This is myself speaking. No company can control my thoughts.]

USENET: N. A self-replicating phage engineered by the phone company to cause
computers to spend large amounts of their owners budget on modem charges.