Path: utzoo!attcan!uunet!dino!ux1.cso.uiuc.edu!brutus.cs.uiuc.edu!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!francis
From: francis@tut.cis.ohio-state.edu (RD Francis)
Newsgroups: news.groups
Subject: Re: Splitting Comp.Sys.Mac again (was Re: Too many messages in ....)
Message-ID: <76758@tut.cis.ohio-state.edu>
Date: 7 Feb 90 16:51:57 GMT
References: <629@ascom.UUCP> <38387@apple.Apple.COM> <1603@umigw.MIAMI.EDU> <38392@apple.Apple.COM>
Reply-To: RD Francis <francis@cis.ohio-state.edu>
Organization: Ohio State University Computer and Information Science
Lines: 31

I have seen a couple of postings now suggesting large numbers of new c.s.m
groups.  Maybe I'm nuts, but perhaps we should try a relatively simple
solution.  I recommend breaking comp.sys.mac into
	comp.sys.mac.software	questions regarding mac software, parallels
				existing group c.s.m.hardware.
	comp.sys.mac.misc	discussions re: interfaces, Apple into the 
				90's, splitting c.b.m, etc.
From what I've seen (and I've been reading the group for quite a while,
albeit sporadically up until the past month or so), this would go a fair way
towards accomplishing two goals:
	1)  division of the load -- I suspect that this comes as close as
		possible to splitting the current messages into two equal
		groups.
	2)  division of interest -- people who are interested in the
		miscellaneous discussions in the group can read them,
		people who want a more "business-like" Q&A approach to
		mac software questions get it minus the discussions.

Of course, I admit the possibility that this is relatively short-sighted,
and would still result in tow groups with a fairly high amount of traffic.
However, I hold that splitting things up much further gets us to the point
where we are creating multiple groups were >90% of the readers of c.s.m.q
would also read c.s.m.x.  In other words, (yes, *please* use other words
if you have them :-) people would wind up having to follow 2,3, or 4 groups
instead of just one to get want they want.  Of course, this is my *opinion*;
I just think that we should add no more complexity than necessary.

RDF

-- 
R David Francis   francis@cis.ohio-state.edu