chuq@plaid.Sun.COM (Chuq Von Rospach) (02/13/88)
Now that comp.sys.mac.programmer is going to be created (unless, of course,
200+ no votes show up in the next six days, which I consider somewhat
unlikely) I think we should start considering where to go next with the Mac
groups.
While I think comp.sys.mac.programmer will help significantly, I don't think
it solves the entire volume problem. I think we are going to need at least
one more, probably two groups, to get things cleaned up. What isn't clear
to me, however, is how to split things up.
One thing I think needs to be looked at is comp.binaries.mac. There's a lot
of material flowing through it, and I'm seeing significant delays in getting
programs out -- delays that, to me, make comp.binaries.mac more or less
useless. I've had a couple of programs and a number of Hypercard stacks that
I haven't bothered to post because the six week plus delays in getting it
onto the net makes it not worth it.
At the same time, though, I don't believe simply cranking up the volume of
comp.binaries.mac is a good idea. So I suggest we look at setting up another
binary group. Two immediate thoughts: comp.binaries.hypercard and
comp.binaries.mac.shareware. The former is obvious. There's a lot of good HC
stuff going on, and enough stacks being generated to keep their own group
going. I could probably be convinced to moderate this unless someone else
wants to do it (I'd rather see someone else do it, really). This would, in
general, probably be an outlet for material that's not getting posted
currently, as well as some of the stuff on comp.binaries.mac.
comp.binaries.mac.shareware isn't as obvious, but I think it'd not only
split comp.binaries.mac fairly cleanly, but also fixes one continuing
philosophical argument on the net. The boundaries are simple. If it charges
a shareware fee, it goes in shareware. If not, it goes in mac. Folks who are
philosophically opposed to using USENET to pass around shareware can not
carry the group. Those of us who don't mind can carry the group. End of
shareware argument (well, probably not, but we can dream). And we can take
comp.binaries.mac and split its volume among two groups and (probably) two
moderators, making life easier on everyone and getting stuff out on a more
timely level.
Anyway, those are my thoughts. comp.binaries.hypercard or comp.binaries.mac.
Or both. Or neither. Or if you have a better idea, let us know.
As far as comp.sys.mac is concerned, I think we need to look at what other
groups are needed. With A/UX now announced and starting to ship, I expect to
start seeing more and more Mac2/Unix. We're also starting to see a lot more
Mac2 related material that isn't generally applicable to all Mac's. I expect
that this trend will probably continue.
Unfortunately, what isn't clear to me is what to do about it. I don't like
the idea of comp.sys.mac2, because a lot of stuff that is relevant to the
Mac2 does belong in comp.sys.mac and I don't like setting up group names at
the same level that will tend towards high levels of cross posting.
One possibility is comp.sys.mac.mac2. Another would be comp.sys.mac.aux,
which would cover the unix stuff. Or perhaps comp.unix.aux. Other
possibilities are comp.sys.mac.games or comp.sys.mac.hardware. I'm not
convinced that any of them are 'right' -- probably the closest based on
watching comp.sys.mac is comp.sys.mac.hardware.
The general philosophy I use when trying to create group names is to come up
with something that conveniently packages a subset of messages in such a way
that there isn't much need to cross post. This is why I'm using
comp.sys.mac.programmer and not comp.sys.mac.tech. Comp.sys.mac.tech covers
a good range of messages, but it's ambiguous, and I feel it'd lead to too
much crossposting. That isn't true of comp.sys.mac.programmer.
All of the group names above, except comp.sys.mac.hardware, are ambiguous to
some degree. And I'm not convinced any of them really address where the next
group name ought to go, so I'm making an initial posting and throwing it
open (with followups forwarded to news.groups only!). This is not, by any
way, shape or form a request for votes or an official proposal. Only a
suggestion that we start looking at it and see if we can come up with a good
name (or set of names) that we can use to set up comp.sys.mac so it works
better than it currently does. comp.sys.mac.programmer helps, but I think
it's a first step. And I want to see what the next step ought to be.
Chuq Von Rospach chuq@sun.COM Delphi: CHUQ
What do you mean 'You don't really want to hurt her?'
I'm a Super-Villain! That's my Schtick!