garnett@cs.utexas.edu (John William Garnett) (03/22/91)
In article <1991Mar21.173105.2755@pslu1.psl.wisc.edu> bill@pslu1.psl.wisc.edu (Bill Roth) writes: >In article <1991Mar21.161808.21001@msuinfo.cl.msu.edu> punch@pleiades.cps.msu.edu (Bill Punch) writes: >>Isn't there someway to take a cue from the mac and amiga people and >>start breaking this newsgroup into some pieces PLEASE!. The traffic is >>getting quite heavy and I for one would appreciate some splitting of >>general/programming/software-dist/hardware type topics, or SOME kind of >>splitting anyway. What would it take to do this? > >I would recommend the following breakdown: > This posting is for: 1) those people who would like to see the benefits of splitting comp.sys.next (without actually necessarily splitting comp.sys.next). 2) those people who have access to a comp.sources.unix archive. 3) those people who can install a new news reader (or ask that it be installed). 4) and everyone else who reads comp.sys.next :-). [note: there is an idea near the end of this message that doesn't require trn in order to be implemented] Recently, a modified version of the rn news reader was posted to comp.sources.unix (and should now be available via anonymous ftp on the uunet.uu.net ftp archive). This new version of rn is known as trn. Trn stands for Threaded ReadNews. Trn allows the user to read news one thread at a time (that is, you can read all messages having a giving subject all together - without having to read messages with other subjects). Trn first presents the user with a screen of thread subjects... the user selects those threads he/she wants to read. After reading the desired threads, the user can use the catchup (c command) feature of rn to cause all remaining messages to be marked as read. Trn drastically cuts down on the next that must be spent skipping unwanted news articles (no more "n n n n n"). This answers the main objections that people have to keeping a mambo-sized single comp.sys.next newsgroup. Idea [this idea answers the rest of the objections <maybe>]: The effects of a split newsgroup could be more closely approximated if each poster to comp.sys.next would always include a "subject area" indication as the first keyword (in the Keywords: field). This would allow the user to search on a given subject area (thus skipping those undesired subject areas). Some would argue that noone will choose to use this "subject area" recommendation. I think that people are just as likely to indicate a subject area in the keywords line as they are to choose the correct subgroup (out of split hierarchy) to post in. There is still the problem with first time posters not knowing about the "subject area" recommendation, but again this is not a big problem because most comp.sys.next posters are repeat posters (or so I would think). If comp.sys.next'ers agree to this "subject area" idea, then it would be appropriate to discuss what the subject area breakdown should be (yes, I think I heard a few "oh no, not that again" groans :-). This way, the subject area breakdown wouldn't necessarily have to be tied to the idea of a split newsgroup (and thus could be discussed more rationally :-). However, implementing the subject area idea now does have the advantage that if it does come to splitting comp.sys.next in the future, the subject areas would be already decided. -- John Garnett University of Texas at Austin garnett@cs.utexas.edu Department of Computer Science Austin, Texas
barry@pico.math.ucla.edu (Barry Merriman) (03/22/91)
In article <259@ar-rimal.cs.utexas.edu> garnett@cs.utexas.edu (John William Garnett) writes: > >The effects of a split newsgroup could be more closely approximated >if each poster to comp.sys.next would always include a "subject area" >indication as the first keyword (in the Keywords: field). This would >allow the user to search on a given subject area (thus skipping those >undesired subject areas). Hey---that sounds like a good idea to me. Actually, it is better than splitting the group. particularly if one uses trn. Can trn be trained to filter things according to the keywords? So, lets decide on a naming convention. Since we are not going to all the trouble of splitting the group, we can try out a very large set of names, and let the unsuccesful ones die out. My votes for subject areas are: System Administration Applications Hardware Programming Miscellaneous These could spawn children, like Programming.Music, or Miscellaneous.Flames, etc. or, we could try a binary version of this classification, for the mathematically inclined; Hardware Primary Peripheral Software Programming User etc. -- Barry Merriman UCLA Dept. of Math UCLA Inst. for Fusion and Plasma Research barry@math.ucla.edu (Internet)
garnett@cs.utexas.edu (John William Garnett) (03/22/91)
In article <1991Mar22.023043.19758@math.ucla.edu> barry@pico.math.ucla.edu (Barry Merriman) writes: >In article <259@ar-rimal.cs.utexas.edu> garnett@cs.utexas.edu (John William Garnett) writes: ]> ]>The effects of a split newsgroup could be more closely approximated ]>if each poster to comp.sys.next would always include a "subject area" ]>indication as the first keyword (in the Keywords: field). This would ]>allow the user to search on a given subject area (thus skipping those ]>undesired subject areas). ] ]Hey---that sounds like a good idea to me. Actually, it is better ]than splitting the group. particularly if one uses trn. ]Can trn be trained to filter things according to the keywords? I'm not sure... If not, we could always include the subject area as the first part of the subject line. In order to allow subject areas with large names we would probably want to develop mnemonics to use as abbreviations. For example, SA: could be system administration. APP: could be applications. HW: could be hardware. PROG: could be programming and MISC: for miscellaneous. ]So, lets decide on a naming convention. Since we are not ]going to all the trouble of splitting the group, we can ]try out a very large set of names, and let the unsuccesful ]ones die out. ] This is true... using this method, we could always easily change the subject areas (whereas we probably couldn't do it easily after splitting group). There could be a weekly posting giving the mnemonics and corresponding subject areas. It also might make it easier to search archives of this newsgroup if postings were pre-categorized. -- John Garnett University of Texas at Austin garnett@cs.utexas.edu Department of Computer Science Austin, Texas
dgc@euphemia.math.ucla.edu (David G. Cantor) (03/23/91)
In article <1991Mar22.023043.19758@math.ucla.edu> barry@pico.math.ucla.edu (Barry Merriman) writes: > . . . So, lets decide on a naming convention. Since we are > not going to all the trouble of splitting the group, we can > try out a very large set of names, and let the unsuccesful > ones die out. > My votes for subject areas are: > System Administration > Applications > Hardware > Programming > Miscellaneous ------------------------------------------------------------------------ These are all excellent, but one important one was omitted: Legal where all the would-be lawyers can give us their best legal advice on the cosmic significance of the fine print in NeXT's licensing agreements and the precise way in which these interpretations apply to the NeXT user in Outer Tasmania. dgc David G. Cantor Department of Mathematics University of California Los Angeles, CA 90024-1555 Internet: dgc@math.ucla.edu
rca@cs.brown.edu (Ronald C.F. Antony) (03/25/91)
In article <1205@cash.cs.utexas.edu> garnett@cs.utexas.edu (John William Garnett) writes: >the first part of the subject line. In order to allow subject areas >with large names we would probably want to develop mnemonics to >use as abbreviations. For example, SA: could be system administration. >APP: could be applications. HW: could be hardware. PROG: could >be programming and MISC: for miscellaneous. > Well, where applicable, I'd prefer if we would stick to the same abbreviations used for the NeXTAnswers files. If someone writes a program that digests all the postings we then could have files with names like: area1_area2__areaN.yymmddhhmm.xx or something like that. Where the date and time is the date and time of the posting of the message normalized to GMT/UTC and xx is a number that distinguishes in the case of colliding names (should be a rare case however..) References to archived articles would also be very short and accurate this way. Ronald ------------------------------------------------------------------------------ "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." G.B. Shaw | rca@cs.brown.edu or antony@browncog.bitnet