rshapiro@bbn.com (Richard Shapiro) (11/22/89)
In article <1989Nov21.170126.7027@aqdata.uucp> sullivan@aqdata.uucp (Michael T. Sullivan) writes: >I see nowhere in the article why rec.video can't be used for software >as well as hardware. What I mean is that nothing in the article said >that there were a lot of postings about software and the hardware >people were getting tired of it. Can we puncture this myth once and for all? IF there's a lot of traffic on an existing newsgroup, that's a good reason to spawn subgroups. BUT THE CONVERSE DOESN'T HOLD! There's no good basis for claiming that a lack of traffic is a reason to oppose a sub-group. There's another much more obvious explanation for this lack, namely that people who are only interested in the sub-topic don't bother posting to the existing group. Maybe it's premature to say so, but I think rec.radio.shortwave is a good example. Some people said "There's an existing group [rec.ham-radio] which hardly anybody uses for this purpose; therefore there's no need for a subgroup." Now that r.r.s'wave exists, there are MANY more shortwave postings there than there ever were on rec.ham-radio. Why? Simple -- there are lots of swl people that didn't read or post to rec.ham-radio. Likewise in this case. If I own a laserdisc player and I just want reviews of discs, do I really want to spend time reading a group that talks almost exclusively about camcorders and s-vhs and editors and the like? Very likely I don't read it and I don't post to it either. Can you conclude from this that a new group wouldn't be useful or busy? Of course not. So can we PLEASE put this bad logic to rest? There may be good reasons to oppose this proposal, but "lack of traffic on existing groups" is not, and cannot be, one of them.
sullivan@aqdata.uucp (Michael T. Sullivan) (11/22/89)
Read the first sentence again: > In article <1989Nov21.170126.7027@aqdata.uucp> sullivan@aqdata.uucp (Michael T. Sullivan) writes: >>I see nowhere in the article why rec.video can't be used for software >>as well as hardware. From article <48601@bbn.COM>, by rshapiro@bbn.com (Richard Shapiro): > > So can we PLEASE put this bad logic to rest? There may be good reasons > to oppose this proposal, but "lack of traffic on existing groups" is > not, and cannot be, one of them. The first sentence merely asks why we need a new group. The following sentence was merely an example. I want to know why rec.video is inadequate and the call for discussion did not address that. -- Michael Sullivan uunet!jarthur.uucp!aqdata!sullivan aQdata, Inc. aqdata!sullivan@jarthur.claremont.edu San Dimas, CA
kanefsky@umn-cs.CS.UMN.EDU (Steve Kanefsky) (11/23/89)
In article <1989Nov21.235219.7624@aqdata.uucp> sullivan@aqdata.uucp (Michael T. Sullivan) writes: >Read the first sentence again: > >> In article <1989Nov21.170126.7027@aqdata.uucp> sullivan@aqdata.uucp (Michael T. Sullivan) writes: >>>I see nowhere in the article why rec.video can't be used for software >>>as well as hardware. > >From article <48601@bbn.COM>, by rshapiro@bbn.com (Richard Shapiro): >> >> So can we PLEASE put this bad logic to rest? There may be good reasons >> to oppose this proposal, but "lack of traffic on existing groups" is >> not, and cannot be, one of them. > >The first sentence merely asks why we need a new group. The following >sentence was merely an example. I want to know why rec.video is inadequate >and the call for discussion did not address that. I believe I did address this question, both in the original call for discussion and in my reply to your article. We need a new newsgroup because many of the people who would contribute to the newsgroup do not and will not read rec.video. Video hardware and movie releases on video are very different subjects. The traffic in rec.video is getting heavier, and the topics covered are becoming too divergent. Are you saying that there is some minimum number of articles that a newsgroup has to have before another newsgroup is created? Sometimes the nature of the topic itself is reason enough. The amount of overhead for a new group would be small in comparison to the time saved by the people who wanted to read just one of them. The nature of the hardware/software distinction should mean that there will be very little if any cross-posting. -- Steve Kanefsky kanefsky@umn-cs.cs.umn.edu