Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!mips!apple!agate!agate!adrianho
From: adrianho@barkley.berkeley.edu (Adrian J Ho)
Newsgroups: comp.graphics
Subject: Re: More discussion on fate of comp.graphics?
Message-ID: <ADRIANHO.91May11023801@barkley.berkeley.edu>
Date: 11 May 91 10:38:01 GMT
References: <1991May9.140834.3564@jarvis.csri.toronto.edu>
	<1991May10.022230.22527@marlin.jcu.edu.au>
	<1991May10.042118.29533@ux1.cso.uiuc.edu>
	<1991May11.073613.12539@marlin.jcu.edu.au>
Sender: root@agate.berkeley.edu (Charlie Root)
Organization: University of California, Berkeley
Lines: 70
In-Reply-To: cppds@marlin.jcu.edu.au's message of 11 May 91 07: 36:13 GMT

In article <1991May11.073613.12539@marlin.jcu.edu.au> cppds@marlin.jcu.edu.au (Peter Stephenson) writes:

>I think you missed my point, Marc, this was what I was saying.
>If we have      comp.graphics
>		   comp.graphics.research
>		   comp.graphics.visualisation
>Gif format requests etc and other noise will just have a bigger market.
>If comp.graphics is disbanded and split into a series of newsgroups
>each of whose name adequately signals the use of the group this will
>simplify matters.

I believe the same thing was proposed for comp.sys.amiga -- look at
the hierarchy now.  EIGHTEEN separate comp.sys.amiga.* groups!!  (And
there might be other groups I'm not receiving <shudder>!)

Your suggestion begs the question: How fine-grained should we split
comp.graphics?  I can think of:

comp.graphics.file-formats	<--\
comp.graphics.file-conversion	<---- not necessarily the same thing
comp.graphics.ray-tracing
comp.graphics.image-processing
comp.graphics.pixutils
comp.graphics.hardware
comp.graphics.algorithms
comp.graphics.misc (or comp.graphics -- catch-all group)
comp.graphics.visualization (don't forget this one 8-)

I'm sure others will be able to think of more.

And there's the problem of the newgroup-voting process -- are we
allowed to vote for all the groups en masse?  I seriously doubt it,
especially since each group would have a different moderator.

>Life won't have changed much for the reader but moderators will have a small
>enough job that someone might actually take up the task and people submitting
>articles will have an idea where their articles are not wanted.

Here's something you may not have considered: What happens when
someone sprays a trivial request across _all_ the groups?  (Don't
laugh -- I've seen it happen too many times to be amused.)  Given that
_all_ (or at least most of) the groups are moderated, who's the lucky
moderator to get the post, or do _all_ of them get it?  A cursory look
at the C News sources suggests _all_, but if anyone knows for sure,
I'd be happy to stand corrected.

Now, if what I've said is correct, here's another problem: There are
also lots of requests that legitimately span several groups.  With
several moderators handling the same request, we'd have to find some
way of coordinating among N moderators, else we'd get a single article
being posted N times.  Anybody know if there's a way around this?

>It is ridiculous to expect all people to adhere to a form of ettique when
>life is easier not to.  A better naming of news groups I believe will be
>of benefit.

The comp.sys.amiga.* hierarchy is pretty well named -- the whole thing
just escalated out of hand.  Perhaps we should take a hard look at
that hierarchy and ask ourselves if we want to go the same way.  (If
it happened there, it could very well happen here, too.)

I vote for a moderated comp.graphics.research, no more (unless
alternatives are suggested to solve the problems I outlined above).
One net.hydra is enough -- let's keep things as simple as possible.

(Sounds like a campaign debate, doesn't it?  8-)

-----------------------------------------------------------------------------
Adrian Ho, EECS (pronounced "eeks!") Dept.		Phone: (415) 642-5563
UC Berkeley					adrianho@barkley.berkeley.edu