cppds@marlin.jcu.edu.au (Peter Stephenson) (05/10/91)
In regards to the discussion for the comp.research, which I fully support,
I think more debate is needed. Like others I don't want to see the discussion
explode into a fury of name proposals but I think more thought is needed.
The question I ask is will comp.graphics.research solve the problems
with comp.graphics? I think not.
You can distribute all the net-ettique
documents you like but you can't make people follow them. People will
still post rogue/gif format requests to comp.graphics.research just as they
do in comp.graphics.visualisation. Another prime example is rec.humor.d,
who ever uses it. People reply directly to rec.humor making the
newsgroup totally pointless and annoying to read.
I believe what has a better chance of working is the splitting of
comp.graphics to a set of news.groups. Most articles to comp.graphics
seem to have subject matter from the following groups:
requests for formats
requests for general graphics information
general research discussion (# of which has dwindled greatly)
announcements (ftp, book, software)
other topics
So why not dis-band the general newsgroup and set up several specialised
news groups. If the names are chosen wisely this may limit the number
of thoughtless postings.
Although comp.graphics.research definitely has my vote and I would like
to see discussion limited to if it is a solution, I have my doubts.
Peter Stephenson
James Cook University of North Queensland
(Up top on the brighter side of Australia)
PS. I'm a late entry to the debate. I apologise if I have repeated
previous points.andreess@mrlaxs.mrl.uiuc.edu (Marc Andreessen) (05/10/91)
In article <1991May10.022230.22527@marlin.jcu.edu.au> cppds@marlin.jcu.edu.au (Peter Stephenson) writes: >I believe what has a better chance of working is the splitting of >comp.graphics to a set of news.groups. Nope nope nope. This wouldn't blunt the onslaught of noise at all. The '.research' label (or its equivalent) will act as a magnet for stupid questions. Moderation, though, would work wonders. (Read comp.compilers to see how high the level of discussion can be kept with a good moderator.) Marc -- Marc Andreessen___________University of Illinois Materials Research Laboratory Internet: andreessen@uimrl7.mrl.uiuc.edu____________Bitnet: andreessen@uiucmrl
cppds@marlin.jcu.edu.au (Peter Stephenson) (05/11/91)
In article <1991May10.042118.29533@ux1.cso.uiuc.edu> andreess@mrlaxs.mrl.uiuc.edu (Marc Andreessen) replies: >>I believe what has a better chance of working is the splitting of >>comp.graphics to a set of news.groups. > >Nope nope nope. This wouldn't blunt the onslaught of noise at all. >The '.research' label (or its equivalent) will act as a magnet for stupid >questions. Moderation, though, would work wonders. 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. 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. 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. Peter Stephenson cppds@groper.jcu.edu.au
adrianho@barkley.berkeley.edu (Adrian J Ho) (05/11/91)
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
fritzz@megatek.UUCP (Frieder Knauss) (05/11/91)
>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-) no no no no no no no! #BHO c.g is a moderately high volume group, but a lot of that is requests for file format converters/source code to do homework with/other mundane stuff. Most of those posts come from people who do not regularly read this news group and are probably not interested in extended discussions (as I imagine those in the other groups would be.) Spawning off a c.g.research would present a forum where a variety of topics could be discussed, most of them of interest to most people. Non regular readers would still go to c.g with their requests, and c.g.research would be mostly left alone. I think one new group is enough, and I think c.g.research is an appropriate name for attracting just those people interested in exactly that: Computer graphics research. #EHO f
murray@sun13.scri.fsu.edu (John Murray) (05/13/91)
Here's one idea that I don't think has been mentioned yet: Instead of creating one or a dozen new groups to solve the misuse of the existing group, what about making the existing group moderated? In my opinion, a new group that is unmoderated won't solve anything for very long, so if we need to go to a moderated group, the appropriate thing to do is to moderate the one we're already using, rather than create a new group and leave the old one to the wolves and wolf pups. -- *Standard Disclaimers Apply*| ---Get Out Of HELL Free!--- John R. Murray |The bearer of this card is entitled to forgive murray@vsjrm.scri.fsu.edu |Himself of all Sins, Errors and Transgressions. Supercomputer Research Inst.| -- D. Owen Rowley
adrianho@barkley.berkeley.edu (Adrian J Ho) (05/13/91)
In article <2965@sun13.scri.fsu.edu> murray@sun13.scri.fsu.edu (John Murray) writes: >Instead of creating one or a dozen new groups to solve the misuse of the >existing group, what about making the existing group moderated? This would be a _tremendous_ burden on the poor moderator, for the following reasons: 1) comp.graphics is essentially a "catch-all" group, ie. queries about the latest-and-greatest image conversion software get posted alongside serious research questions. There are only (to my knowledge) two other graphics-related groups: alt.graphics.pixutils and comp.graphics.visualization. The former is not carried universally (or even a reasonable approximation thereof, the alt.hierarchy being what it is), and the latter's charter is pretty restrictive. Hence, the volume of mail that the moderator would have to sift through would be daunting. 2) Making comp.graphics moderated puts the moderator in a dilemma: How does s/he handle the myriad and repetitive requests for GIF viewers and other graphics-related software? Posting these requests, especially the commonly recurring ones, would probably piss the general readership off, but it's hardly reasonable to expect the moderator to reply personally to all these requests. The effectiveness of a regularly-posted FAQ (thanks much, Jef) seems to be impacted somewhat by sites that have short expiry periods, and by new readers who don't know of its existence (possibly because of the early expiry). >In my opinion, a new group that is unmoderated won't solve anything for very >long, so if we need to go to a moderated group, the appropriate thing to do >is to moderaue the one we're already using, rather thao create a new group >and leave the old one to the wolves and wolf pups. I believe that the original idea was to create comp.graphics.research as a moderated group, and leave comp.graphics as it is. Given the content of existing traffic on comp.graphics, I think this is the best idea proposed so far. Since this is the second proposal that I'm rebutting, it seems appropriate that I extend my apologies to anyone who might have been offended by the tone of my first rebuttal (the one about having multiple moderated comp.graphics.* groups). I shall endeavour to refrain from posting net.news while "high" on 4 cans of Jolt and no sleep for two days. 8-) ----------------------------------------------------------------------------- Adrian Ho, EECS (pronounced "eeks!") Dept. Phone: (415) 642-5563 UC Berkeley adrianho@barkley.berkeley.edu
mcdonald@aries.scs.uiuc.edu (Doug McDonald) (05/13/91)
In article <2965@sun13.scri.fsu.edu> murray@sun13.scri.fsu.edu (John Murray) writes: >Here's one idea that I don't think has been mentioned yet: > >Instead of creating one or a dozen new groups to solve the misuse of the >existing group, what about making the existing group moderated? > >In my opinion, a new group that is unmoderated won't solve anything for very >long, so if we need to go to a moderated group, the appropriate thing to do >is to moderate the one we're already using, rather than create a new group >and leave the old one to the wolves and wolf pups. > >-- >*Standard Disclaimers Apply*| ---Get Out Of HELL Free!--- >John R. Murray |The bearer of this card is entitled to forgive >murray@vsjrm.scri.fsu.edu |Himself of all Sins, Errors and Transgressions. >Supercomputer Research Inst.| -- D. Owen Rowley This would probably result in its death: nobody would moderate it. Moderating a presently unmoderated and very popular group with the express intent of rejecting most of the submissions would result in disaster. Where else would the present submissions go but to the moderator? If he sends them on, the readers who would like a comp.graphics.research would get mad. If he refuses to send them on, the rejectees would deluge him - and news.groups - and, indeed, perhaps the people who voted for moderation - with extremely inflammatory mail. Comp.graphics is presently a VERY successful group. I find it extremely useful. If you want something different - something moderated, simply start up a new group. I would vote for that. I would vote against moderating this group. Doug McDonald
rdippold@cancun.qualcomm.com (Ron Dippold) (05/14/91)
In article <2965@sun13.scri.fsu.edu> murray@sun13.scri.fsu.edu (John Murray) writes: >ucp> >Followup-To: comp.graphics >Organization: SCRI, Florida State University >Lines: 15 > >Here's one idea that I don't think has been mentioned yet: > >Instead of creating one or a dozen new groups to solve the misuse of the >existing group, what about making the existing group moderated? > >In my opinion, a new group that is unmoderated won't solve anything for very >long, so if we need to go to a moderated group, the appropriate thing to do >is to moderate the one we're already using, rather than create a new group >and leave the old one to the wolves and wolf pups. So then what are you going to do with all the irritating, but legitimate, requests for XXXX viewer for machine YYYY? If you let them through, you haven't gained anything. If you don't let them through, you've cut off one of the few groups they can ask it on with some hope of answer. -- Standard disclaimer applies, you legalistic hacks. | Ron Dippold
will@rins.ryukoku.ac.jp (will) (05/14/91)
In article <4921@sahara.megatek.uucp>, fritzz@megatek.UUCP (Frieder Knauss) writes: >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-) Agreed, a double no, no, no, no, no. defenatly not. Keep it simple. My work is complicated enough, without others making it more complicated. 3 groups that's it. Will..... My opinions have been expressed...........But usaually don't mean much
simona@panix.uucp (Simona Nass) (05/18/91)
In article <1991May13.182057.24163@qualcomm.com> rdippold@cancun.qualcomm.com (Ron Dippold) writes: >In article <2965@sun13.scri.fsu.edu> murray@sun13.scri.fsu.edu (John Murray) writes: >>ucp> >>Followup-To: comp.graphics >>Organization: SCRI, Florida State University >>Lines: 15 >> >>Here's one idea that I don't think has been mentioned yet: >> >>Instead of creating one or a dozen new groups to solve the misuse of the >>existing group, what about making the existing group moderated? >> >>In my opinion, a new group that is unmoderated won't solve anything for very >>long, so if we need to go to a moderated group, the appropriate thing to do >>is to moderate the one we're already using, rather than create a new group >>and leave the old one to the wolves and wolf pups. > >So then what are you going to do with all the irritating, but legitimate, >requests for XXXX viewer for machine YYYY? If you let them through, you >haven't gained anything. If you don't let them through, you've cut off >one of the few groups they can ask it on with some hope of answer. > > >-- >Standard disclaimer applies, you legalistic hacks. | Ron Dippold I am strongly opposed to moderating it, but would like to see it broken down into sub-groups, perhaps at least: - one for image requests and discussion about same - one about the technology (how-to, opinions about viewers, etc.) -S. -- ( rutgers!cmcl2!panix!simona, uunet!jyacc!david, simona@panix.uucp )