fransvo@maestro.htsa.aha.nl (Frans van Otten) (05/26/89)
Karl Heuer writes: >Frans van Otten writes: > >|... If someone has a serious question, he or she can ask it in the >|moderated group. If the group is known as a high quality one, >|interest in the unmoderated group will cease. > >That sounds reasonable, but it doesn't work that way in practice. If >you have two groups with essentially the same charter, but only one >is moderated, the unmoderated one gets all the traffic. This may be true, I don't know. But anyway: What would be the use of an unmoderated group next to a moderated group ? >If there's a problem with too much noise here, the solution should be >to make comp.lang.c itself moderated. Yes, I think that's the best solution. I would vote for this. Or is there any good reason to keep comp.lang.c unmoderated ? Now, who wants to become eternally famous as The Comp.Lang.C - Moderator ? -- Frans van Otten | fransvo@maestro.htsa.aha.nl or Algemene Hogeschool Amsterdam | fransvo@htsa.uucp or Technische en Maritieme Faculteit | [[...!]backbone!]htsa!fransvo
mcdonald@uxe.cso.uiuc.edu (05/29/89)
>Frans van Otten writes: > >|... If someone has a serious question, he or she can ask it in the >|moderated group. If the group is known as a high quality one, >|interest in the unmoderated group will cease. > >That sounds reasonable, but it doesn't work that way in practice. If >you have two groups with essentially the same charter, but only one >is moderated, the unmoderated one gets all the traffic. If comp.lang.c is made moderated, there really SHOULD be a parallel unmoderated group. Moderated groups are NEVER as successful as unmoderated ones At least I've never seen one. What might be better is a moderated comp.lang.c.excerpts, where a moderator censors the regular comp.lang.c, so persons who are sufficiently lazy to run through it all can look at the summary, a week or a month or a year late!!! Doug McDonald
fransvo@maestro.htsa.aha.nl (Frans van Otten) (05/30/89)
Doug McDonald writes: >If comp.lang.c is made moderated, there really SHOULD be a parallel >unmoderated group. Moderated groups are NEVER as successful as >unmoderated ones. At least I've never seen one. How do you measure successfullness ? Do you also count flame wars and multiple answers to the same question ? If this this is true, what are the reasons ? (Maybe speed ? A moderated group is somewhat slower than an unmoderated group.) >What might be better is a moderated comp.lang.c.excerpts, where a moderator >censors the regular comp.lang.c, so persons who are sufficiently >lazy to run through it all can look at the summary, a week or a month or >a year late!!! A moderator is not for the service of lazy readers. A moderator is to guard the contents of the newsgroup. Also, I think it is useful to try to keep the net volume low, instead of increasing it. Although flamewars and alike can be fun to read, I really don't think they belong in a group like this one. -- Frans van Otten | fransvo@maestro.htsa.aha.nl or Algemene Hogeschool Amsterdam | fransvo@htsa.uucp or Technische en Maritieme Faculteit | [[...!]backbone!]htsa!fransvo
peter@ficc.uu.net (Peter da Silva) (05/30/89)
In article <225800171@uxe.cso.uiuc.edu>, mcdonald@uxe.cso.uiuc.edu writes: > What might be better is a moderated comp.lang.c.excerpts, where a moderator How about comp.lang.c.funny? -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
henry@utzoo.uucp (Henry Spencer) (05/30/89)
In article <225800171@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: >If comp.lang.c is made moderated, there really SHOULD be a parallel >unmoderated group. Moderated groups are NEVER as successful as unmoderated ones >At least I've never seen one. Obviously you haven't looked at comp.risks lately. Or, for that matter, rec.humor.funny (does *anyone* read rec.humor itself any more? :-)). There are successful moderated groups. Much depends on the level of effort the moderator can put into it. >What might be better is a moderated comp.lang.c.excerpts, where a moderator >censors the regular comp.lang.c, so persons who are sufficiently >lazy to run through it all can look at the summary, a week or a month or >a year late!!! This sort of thing has been tried once or twice. It doesn't work too well. Being moderator is a thankless job at best, and doing it this way it's worse. Most people prefer interactive discussions, not summaries of long-dead ones. -- Van Allen, adj: pertaining to | Henry Spencer at U of Toronto Zoology deadly hazards to spaceflight. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
jcbst3@unix.cis.pittsburgh.edu (James C. Benz) (06/01/89)
In article <934@maestro.htsa.aha.nl> fransvo@htsa.UUCP (Frans van Otten) writes: >Yes, I think that's the best solution. I would vote for this. Or is >there any good reason to keep comp.lang.c unmoderated ? I vote for unmoderated. As many of the readers of this group already know, I often post *really* stupid questions, some of which I already know the answer to, but just don't know I know. In a moderated group, a question the moderator thinks is stupid might not get through the filter, but the person posting it (me) thinks it is mighty important, and may be sitting around tearing their hair out looking for an answer. If the group is only going to be useful to those who post *really* good questions, a lot of the utility of this group will be lost. -- Jim Benz jcbst3@unix.cis.pittsburgh.edu If a modem University of Pittsburgh answers, UCIR (412) 648-5930 hang up!
visinfo@ethz.UUCP (VISINFO Moderators) (06/05/89)
In my opinion, the comp.lang.c should be splitted in some more specific areas, as 'source-problems', 'compilers' etc., which wouldn't be moderated. The current situation is rather tiring: looking at comp.lang.c (mostly in one-week- period), I usually find ~200 new articles. It takes me then 2 or 3 hours to read ... Tony +++ Murphy's Law's derivation: 'Mother Nature is a bitch'.
fransvo@maestro.htsa.aha.nl (Frans van Otten) (06/06/89)
Jim Benz writes: >I vote for unmoderated ... In a moderated group, a question the >moderator thinks is stupid might not get through the filter, but >the person posting it thinks it is mighty important... I don't think this moderator would be a good one. His or her task is to prevent nonsense, flame wars etc. Also, multiple answers to the same question can be filtered out. But filtering out stupid questions (which are actually C questions !) is definitely NOT the task of the moderator. -- Frans van Otten | fransvo@maestro.htsa.aha.nl or Algemene Hogeschool Amsterdam | fransvo@htsa.uucp or Technische en Maritieme Faculteit | [[...!]backbone!]htsa!fransvo
guy@auspex.auspex.com (Guy Harris) (06/07/89)
>I vote for unmoderated. As many of the readers of this group already know, >I often post *really* stupid questions, some of which I already know the >answer to, but just don't know I know. In a moderated group, a question the >moderator thinks is stupid might not get through the filter, but the person >posting it (me) thinks it is mighty important, and may be sitting around >tearing their hair out looking for an answer. If the answer is of general interest, and is expected to be of use to a large portion of the audience, a good moderator will let it through. If the answer is *not* of general interest, I would hope the moderator would mail the answer back to the poster.
karl@haddock.ima.isc.com (Karl Heuer) (06/07/89)
In article <18227@unix.cis.pittsburgh.edu> jcbst3@unix.cis.pittsburgh.edu (James C. Benz) writes: >How about comp.lang.c.bsd, comp.lang.c.sysv, comp.lang.c.pc, comp.lang.c.mac? Questions that are really about the compilation or execution environment rather than C itself (e.g. "How do I print sideways on the paper? I'm using C.") should go to the appropriate comp.sys group *instead* of comp.lang.c. This problem can be solved by moderation, or partially reduced by education. Or it can be ignored. In article <18230@unix.cis.pittsburgh.edu> jcbst3@unix.cis.pittsburgh.edu (James C. Benz) writes: >I vote for unmoderated. As many of the readers of this group already know, >I often post *really* stupid questions, some of which I already know the >answer to, but just don't know I know. In a moderated group, a question the >moderator thinks is stupid might not get through the filter, but the person >posting it (me) thinks it is mighty important, and may be sitting around >tearing their hair out looking for an answer. So, let's draw up a charter: The moderator shall not reject a question for being "stupid". He/she may reject an *answer* for being wrong ("int is always 32 bits") or redundant (the 25th consecutive posting saying "no it isn't"), or any posting for being inappropriate ("How do you pronounce `#'?"). Does this sound reasonable? Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint
campbell@redsox.bsw.com (Larry Campbell) (06/07/89)
In article <13607@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes:
-So, let's draw up a charter: The moderator shall not reject a question for
-being "stupid". He/she may reject an *answer* for being wrong ("int is always
-32 bits") or redundant (the 25th consecutive posting saying "no it isn't"), or
-any posting for being inappropriate ("How do you pronounce `#'?"). Does this
-sound reasonable?
Top on my list of "inappropriate" questions would be "So how come C is case
sensitive?"
--
Larry Campbell The Boston Software Works, Inc.
campbell@bsw.com 120 Fulton Street
wjh12!redsox!campbell Boston, MA 02146karzes@mfci.UUCP (Tom Karzes) (06/08/89)
In article <13607@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes: > >So, let's draw up a charter: The moderator shall not reject a question for >being "stupid". He/she may reject an *answer* for being wrong ("int is always >32 bits") or redundant (the 25th consecutive posting saying "no it isn't"), or >any posting for being inappropriate ("How do you pronounce `#'?"). Does this >sound reasonable? I question the ability of a moderator to reject an *answer* for being wrong. I see no reason to believe that a moderator, no matter how chosen, would necessarily have a more complete or more correct understanding of a given issue than a given poster or reader. True, considering the fact that many people who try to post answers don't have a clue about C and appear to have 2 digit IQ's, and assuming a moderator could be found who doesn't suffer from these shortcomings, this might work for 90% of the answers. However, I suspect there would still be occasions when a moderator wouldn't understand a subtle point, but would *think* that he/she did, and would incorrectly throw away a key response as being "incorrect" or "redundant", depriving those of us who are able to appreciate such a posting from seeing it. To put it another way, I'd rather weed out a bit of garbage than risk missing a few hastily discarded gems.
bengsig@oracle.nl (Bjorn Engsig) (06/08/89)
In article <13607@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes: >So, let's draw up a charter: The moderator shall not reject a question for >being "stupid". He/she may reject an *answer* for being wrong ("int is always >32 bits") or redundant (the 25th consecutive posting saying "no it isn't"), or >any posting for being inappropriate ("How do you pronounce `#'?"). Does this >sound reasonable? Yes Karl, it does sound reasonable, but I do not think that we can have the same vivid group if it were moderated. It is true that we sometimes have too much garbage around here, but I wouldn't miss the sometimes very tight discussions, which is not the same with a moderation. You also have to think about us here in Europe, where a moderation could easily lead to two days delay. These days, with the new mcvax-uunet link, the effective delivery time is measured in hours, which enables us to take part in tight discussions. We still have the 'k' key, which is quite a good way to do your own moderation, and maybe we should try (again) with some education of posters and in particular "Re:"-posters. Personally, I use the 'R' key more often than I use the 'F' key, and let the original poster decide upon posting a followup. I would definately vote against moderation and against creation of a parallel moderated group. If you look at comp.unix, the S/N ratio is very high, but it doesn't really help when the signal itself is close to zero. Another idea that has been seen, is to make a distinction like comp.unix.questions for novices and comp.unix.wizards for more experienced, but since we cannot force guys like Doug, Chris, yourself and others to read them both, we might end up with good questions without qualified answers, or worse, with wrong answers. Let us stick to the comp.lang.c, which we have learned to love and to hate. It is a wonderful, vivid group. -- Bjorn Engsig, ORACLE Europe \ / "Hofstadter's Law: It always takes Path: mcvax!orcenl!bengsig X longer than you expect, even if you Domain: bengsig@oracle.nl / \ take into account Hofstadter's Law"
phil@ux1.cso.uiuc.edu (06/08/89)
> Top on my list of "inappropriate" questions would be "So how come C is case > sensitive?" On which newsgroup IS it appropriate. Inquiring minds might want to know the real history behind the decision to make C case sensitive. Is discussion of the history of the C language inappropriate on comp.lang.c? --Phil howard-- <phil@ux1.cso.uiuc.edu>
guy@auspex.auspex.com (Guy Harris) (06/09/89)
>To put it another way, I'd rather weed out a bit of garbage than risk >missing a few hastily discarded gems. Given the amount of garbage I've seen, I'm willing to take the risk of losing a few gems. I think most prospective moderators can distinguish between obvious garbage and subtle but correct answers; one would hope that they would, in cases other than obviously bogus postings (and, time permitting, even in those cases, in the hopes of setting the poster straight) they'd respond to the poster by mail. If the poster felt that the moderator didn't understand the posting, they could explain it in more detail in a reply (if the moderator is reasonably knowledgable, but missed the pointer anyway, it may well indicate that the point needs to be stated more clearly) in which case the moderator might let the improved version through.
flee@shire.cs.psu.edu (Felix Lee) (06/09/89)
In article <890@m3.mfci.UUCP>, karzes@mfci.UUCP (Tom Karzes) writes: >I question the ability of a moderator to reject an *answer* for being >wrong. The key is the time delay. Presumably, the moderator will get a handful of different replies in the same timeslice, from which he/she can read and weed out the repetitive and wrong. Rather than having postings instantaneously blatted out from the fingers to the newsgroup without intervening thought. -- Felix Lee flee@shire.cs.psu.edu *!psuvax1!shire!flee
tcm@srhqla.UUCP (Tim Meighan) (06/09/89)
In article <1781@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >If the poster felt that the moderator didn't understand the posting, >they could explain it in more detail in a reply (if the moderator is >reasonably knowledgable, but missed the pointer anyway, it may well >indicate that the point needs to be stated more clearly) That won't work; it's meaningless to add to pointers. Tim Meighan SilentRadio
tneff@bfmny0.UUCP (Tom Neff) (06/09/89)
In article <6200007@ux1.cso.uiuc.edu> this guy phil@ux1.cso.uiuc.edu writes: >On which newsgroup IS it appropriate. Inquiring minds might want to know the >real history behind the decision to make C case sensitive. Is discussion of >the history of the C language inappropriate on comp.lang.c? I think the "inappropriate" tag on this question has more to do with the "why question that which you cannot change" attitude. It's not the only valid attitude in the world but it's a useful one when holding down bandwidth is an ongoing goal. :-) I regret that I cannot provide historical reasons why C was case sensitive, but since we have Ritchie and others on the net I'm sure the answer will be forthcoming. As a user I'd just like to say that I find it PERFECTLY REASONABLE to do business this way. Case sensitivity encourages an orderly editorial style towards identifiers. And if you get one wrong the compiler tends to let you know IMMEDIATELY, so what's the danger. Programmers tend not to have things like "i" and "I" in the same module in my experience, so the risk of total misidentification seems small. Lint cures many things. Meanwhile you are spared the specter of a junior programmer tacking something onto YOUR code with completely different and unreadable case conventions, and having the d*** thing COMPILE OK, as often happens with me and PL/M. (PL/M is even worse because dollar signs aren't significant in identifiers -- get$next$block and GETNEXTBLOCK and g$E$t$N$e$X$t$B$$$$$$$$$$l$$$O$$c$K are all the same identifier.) -- You may redistribute this article only to those who may freely do likewise. -- Tom Neff UUCP: ...!uunet!bfmny0!tneff "Truisms aren't everything." Internet: tneff@bfmny0.UU.NET
ray@philmtl.philips.ca (Raymond Dunn) (06/10/89)
What we really need is not a moderator, but someone who is willing to provide an *extraction* service. Moderation is too inhibiting and stifling for this sort of newsgroup. Let some brave soul read comp.lang.c, cull the nonsense, and republish the "worthwhile" bits in say comp.lang.c.extracts. He must of course sign the pledge not to re-publish this compilation at Christmas time either for gain, or to amuse his relatives (:-). -- Ray Dunn. | UUCP: ..!uunet!philmtl!ray Philips Electronics Ltd. | TEL : (514) 744-8200 Ext: 2347 600 Dr Frederik Philips Blvd | FAX : (514) 744-6455 St Laurent. Quebec. H4M 2S9 | TLX : 05-824090
karl@haddock.ima.isc.com (Karl Heuer) (06/13/89)
In article <6200007@ux1.cso.uiuc.edu> phil@ux1.cso.uiuc.edu writes: >> Top on my list of "inappropriate" questions would be "So how come C is case >> sensitive?" > >On which newsgroup IS it appropriate. This particular question is really a comparison between C and some case-blind language, and should be discussed in comp.lang.misc. Similarly, most discussions about a proposed "D" language should go there. Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint