SRFERGU@ERENJ.BITNET (Scott Ferguson) (12/19/89)
I think it would be more proper for those with large numbers of problems to send them in one long message, thus saving time on the internet, as well as making them all easier to get through instead of wading through hundreds of lines of message headers. Anyone else care to comment? Scott Ferguson
lori@hacgate.scg.hac.com (Lori Barfield) (12/19/89)
In article <8912181633.AA12104@umix.cc.umich.edu> SRFERGU@ERENJ.BITNET (Scott Ferguson) writes: > >I think it would be more proper for those with large numbers of problems >to send them in one long message, thus saving time on the internet, as well >as making them all easier to get through instead of wading through >hundreds of lines of message headers. > >Anyone else care to comment? I disagree. If a message header says "Multifarious and Sundry Questions," how are you going to know to 'n' past it without reading the whole darn thing? Then what if the discussion goes in three different directions? I think even tiny questions on unrelated topics should be posted individually, so we can read all the messages we want in a given day's crop, then 'c' the rest away. Also, sometimes trivial issues become meaty discussions, and if they start out under an inappropriate or nebulous Subject:, then one could miss an enlightening debate. I do suggest, however, that SR9-specific issues have SR9 in the Subject: so SR10 people can kill these out. Also, Unix- or Aegis- specific topics might also contain those keywords in the Subject:. And if DN10k-type discussions have that in the header, the rest of us Motorola-bound admins can just disregard. I say put this info in the Subject: because kill files work lots faster when that's the only place they have to look, and a quick scan of the Subject: lines is what I do first when I log in. For me, it's not the number of messages, but getting to the right ones quickly. ...lori
paul@CAEN.ENGIN.UMICH.EDU (paul killey) (12/22/89)
There is something to be said for putting things together in fewer messages to this list. Especially in that this is not a formal bug reporting channel to apollo. On the other hand, people should feel that they have the latitude to make their own decision about how they want to present material here. Understanding that they may hear back from recipients, etc. (Bland enough? -:)) From the standpoint of this mailing list, I have decrufted it quite a bit (getting rid of broken addresses and trying to be much more prompt about requests to apollo-request) so there weren't a lot of bounces. But there are always two or three VMS machines where a recipient has used all their disk space and the message couldn't be delivered. --paul