Proposal: new groups in comp.sys.mac.programmer hierarchy

[Simon Fraser]

This is an informal suggestion for the creation of several new
groups in the comp.sys.mac.programmer hierarchy. It is a precursor
to a more formal Request For Discussion (RFD) on the creation of
these groups.


PROPOSED NEW GROUPS

comp.sys.mac.programmer.carbon
Programming using the Carbon APIs on Mac OS X

comp.sys.mac.programmer.cocoa
Programming using the Cocoa APIs on Mac OS X

comp.sys.mac.programmer.xcode
Apple's Xcode development environment


CHARTERS

comp.sys.mac.programmer.carbon
------------------------------

comp.sys.mac.programmer.carbon is an unmoderated group for the
discussion of the use of the Carbon application programming
interfaces on Mac OS. The Carbon API is a rich set of interfaces ,
both high- and low-level, that allowed developers to migrate their
applications from Classic Mac OS, yet continue to be supported as a
first-class set of interfaces by Apple.

It is anticipated that most of the discussion will related to issues
on Mac OS X, yet the Carbon APIs are also available on Classic Mac
OS (i.e. Mac OS 9) and so programming questions relating to earlier
system versions would be suitable for this group.

Posts should relate to the Carbon programming interfaces themselves,
and not to issues with programming languages or development
environments, as other groups exist for those topics.

Posters are expected to abide by normal Usenet standards of decorum,
and to ignore articles intended to disrupt the group. The usual
suspects are prohibited (spam, binaries, direct advertising, etc.)


comp.sys.mac.programmer.cocoa
-----------------------------

comp.sys.mac.programmer.cocoa is an unmoderated group for the
discussion of the Cocoa application programming interfaces on Mac OS
X. Cocoa is a framework which provides a rich set of interfaces for
application programming, and is currently Apple's recommended
framework for application development. Cocoa interfaces use the
Objective-C programming language.

Posts should relate to the Cocoa programming interfaces themselves,
and not to issues with programming languages or development
environments, as other groups exist for those topics. In particular,
Objective-C questions should be posted to comp.lang.objective-c .

Posters are expected to abide by normal Usenet standards of decorum,
and to ignore articles intended to disrupt the group. The usual
suspects are prohibited (spam, binaries, direct advertising, etc.)


comp.sys.mac.programmer.xcode
-----------------------------

comp.sys.mac.programmer.xcode is an unmoderated group for the
discussion of the Xcode programming environment on Mac OS X. Xcode
is an integrated development environment (IDE), and is provided by
Apple as part of their developer tools.

Expected topics for discussion include configuration of Xcode
projects, porting from other development systems to Xcode, using the
integrated debugger, and using the data modeling and design features
of Xcode.

Posts should relate to the use of the Xcode IDE itself, and not to
system APIs and programming languages used for projects compiled
with Xcode, as other groups exist for those purposes.

** open issue: does discussion of Interface Builder and Dashcode fit
here? **

Posters are expected to abide by normal Usenet standards of decorum,
and to ignore articles intended to disrupt the group. The usual
suspects are prohibited (spam, binaries, direct advertising, etc.)


RATIONALE

The group hierarchies "comp.sys.mac.oop" and
"comp.sys.mac.programmer" reflect the Mac programming universe
largely before the advent of Mac OS X, and have not been updated
despite major shifts in available Mac programming tools and
technologies.

One of the historically busiest groups,
comp.sys.mac.programmer.codewarrior, concerns a product that has now
been discontinued, yet there is no group dedicated to Xcode, which
is currently the most widely used development environment on Mac OS
X. Similarly, there are no groups dedicated to the two major
programming interfaces on Mac OS X, namely Cocoa and Carbon.

This proposal suggests the creation of three new groups which cover
the most popular development environment, and programming interfaces
in use on Mac OS X today. These groups will allow Mac developers to
find a more appropriate group for their development questions, and
will reduce the amount of cross-posting needed today to hit the
right audience for a post.


DISCUSSION

The three new groups proposed herein should allow many questions
currently posted to comp.sys.mac.programmer.help,
comp.sys.mac.programmer.misc and comp.sys.mac.programmer.tools to be
addressed to a more focused group.

The structure of the c.s.m.oop and c.s.m.p hierarchies is not ideal,
and one of the goals of any group rearrangement here should be to
clean up those sets of groups. In line with that proposal, the
suggestion could be made to create comp.sys.mac.oop.cocoa, rather
than comp.sys.mac.programmer.cocoa. In the c.s.m.oop hierarchy,
.cocoa would sit nicely alongside .powerplant, .tcl and .macapp3.

I decided against comp.sys.mac.oop.cocoa for two reasons. First,
developers often view Carbon and Cocoa as alternates, arguing for
groups relating to those two technologies being peers in the
hierarchy. Carbon is not an object-oriented API, suggesting both
live under comp.sys.mac.programmer, as I propose here.

Secondly, many Cocoa questions get posted now to c.s.m.p.misc and
c.s.m.p.help, and sending users off to a new group in the c.s.m.oop
hierarchy would be disorienting for those people. The "oop" implies
more of theoretical discussion of object-oriented programming with a
given API, rather than a nuts-and-bolts "how to get it done"
discussion.

There are a fair number of AppleScript questions posted to the
c.s.m.programmer groups, which argues for the creation of
comp.sys.mac.programmer.applescript. However,
alt.comp.lang.applescript already exists. If there appears to be
demand, comp.sys.mac.programmer.applescript could be created in a
later phase.

It was unfortunate that comp.sys.mac.programmer.codewarrior wasn't
created as comp.sys.mac.programmer.tools.codewarrior, since the
addition of groups for additional tools, like Xcode and Interface
Builder, would then fit nicely as
comp.sys.mac.programmer.tools.xcode etc. However, here we bow to
precedent and propose comp.sys.mac.programmer.xcode.

Although these new groups cover the most frequent areas of
discussion, there are certain topics that don't fit nicely into
existing or proposed groups. For example, where would one post about
using Core Foundation, or lower level UNIX calls? Do posts about
Interface Builder and Dashcode belong in
comp.sys.mac.programmer.xcode? Feedback is welcome on these
questions.

[matt neuburg]

Post by Simon Fraser
This is an informal suggestion for the creation of several new
groups in the comp.sys.mac.programmer hierarchy. It is a precursor
to a more formal Request For Discussion (RFD) on the creation of
these groups.
PROPOSED NEW GROUPS
comp.sys.mac.programmer.carbon
Programming using the Carbon APIs on Mac OS X
comp.sys.mac.programmer.cocoa
Programming using the Cocoa APIs on Mac OS X
comp.sys.mac.programmer.xcode
Apple's Xcode development environment

Traffic on comp.sys.mac.programmer.help is extremely light (most of the
discussion being over on Apple's lists, which already make the suggested
division). Usenet is definitely not the mainstream place for this stuff
any more. So perhaps there's no very good reason not to leave things as
they are...?

m.

[Michael Ash]

Post by matt neuburg

Post by Simon Fraser
This is an informal suggestion for the creation of several new
groups in the comp.sys.mac.programmer hierarchy. It is a precursor
to a more formal Request For Discussion (RFD) on the creation of
these groups.
PROPOSED NEW GROUPS
comp.sys.mac.programmer.carbon
Programming using the Carbon APIs on Mac OS X
comp.sys.mac.programmer.cocoa
Programming using the Cocoa APIs on Mac OS X
comp.sys.mac.programmer.xcode
Apple's Xcode development environment

Traffic on comp.sys.mac.programmer.help is extremely light (most of the
discussion being over on Apple's lists, which already make the suggested
division). Usenet is definitely not the mainstream place for this stuff
any more. So perhaps there's no very good reason not to leave things as
they are...?

I agree. The only reason to split these things up into topics is if there
were so much traffic in the groups that exist that people couldn't filter
it all out and just read the stuff they wanted. Somebody who was
Cocoa-centric might find it too frustrating to ignore all of the Carbon
talk if it was all piled together, but would happily subscribe to
csmp.cocoa.

But traffic is light, and the people who do manage to discover the
newsgroups tend to be of the mentally flexible types who can consider
using both Carbon and Cocoa. I anticipate that creating separate groups
will either lead to the new ones being ignored, or everybody who subscibes
to the old ones subscribing to all of the new ones, with no net gain.

[Sherm Pendley]

Post by matt neuburg

Post by Simon Fraser
This is an informal suggestion for the creation of several new
groups in the comp.sys.mac.programmer hierarchy. It is a precursor
to a more formal Request For Discussion (RFD) on the creation of
these groups.
PROPOSED NEW GROUPS
comp.sys.mac.programmer.carbon
Programming using the Carbon APIs on Mac OS X
comp.sys.mac.programmer.cocoa
Programming using the Cocoa APIs on Mac OS X
comp.sys.mac.programmer.xcode
Apple's Xcode development environment

Traffic on comp.sys.mac.programmer.help is extremely light

Bullseye on the first shot. The amount of traffic is traditionally the
determining factor in splitting a new group off from its parent, and there
isn't *nearly* enough traffic here to warrant that.

sherm--

[slashlos]

Post by matt neuburg
Traffic on comp.sys.mac.programmer.help is extremely light (most of the
discussion being over on Apple's lists, which already make the suggested
division). Usenet is definitely not the mainstream place for this stuff
any more. So perhaps there's no very good reason not to leave things as
they are...?
m.

Well from a noob's perspective I agree, as I'm trying wide this 3d
paradigm of Xcode, Cocoa and Objective C. It would also be easier for
more learned readers to filter noob noise by have a central place. ;-)

[Sherm Pendley]

Post by slashlos
It would also be easier for
more learned readers to filter noob noise by have a central place. ;-)

I've seen this proposed before, in other group hierarchies, and even tried
in a few. It never works, for two reasons:

Many advanced users *want* to see the noob's posts, because they want to
answer the noobs and be helpful.

Quite a few noobs will post their questions to the "advanced" forum anyway.

sherm--

[Michael Ash]

Post by Sherm Pendley

Post by slashlos
It would also be easier for
more learned readers to filter noob noise by have a central place. ;-)

I've seen this proposed before, in other group hierarchies, and even tried
Many advanced users *want* to see the noob's posts, because they want to
answer the noobs and be helpful.
Quite a few noobs will post their questions to the "advanced" forum anyway.

I haven't experienced it on usenet, but I've seen it happen once on IRC
and one on a mailing list. In both cases, the so-called "advanced" forum
was primarily popuulated by people who thought that writing a small
addition to Currency Converted qualified as advanced, and by people who
thought that since advanced people should be much better at answering
their questions, they'd ask all of their "I can't print" questions in the
advanced forum.

In both cases, the advanced forum was completely worthless from the outset
and I abandoned them rapidly.

In the case of, say, the cocoa-dev mailing list it would be nice to have
the non-stop repetitive redundant "I can't print" questions partitioned
off into another place. Not so much because of the questions, but because
they inevitably attract half a dozen wrong answers from the list before
somebody who knows what's going on weighs in, and my correction twitch
just can't stand a subscription to the list. But I realize that, no matter
how nice it might be in theory, in practice it simply won't work.

[Gregory Weston]

Post by Simon Fraser
This is an informal suggestion for the creation of several new
groups in the comp.sys.mac.programmer hierarchy. It is a precursor
to a more formal Request For Discussion (RFD) on the creation of
these groups.
PROPOSED NEW GROUPS
comp.sys.mac.programmer.carbon
Programming using the Carbon APIs on Mac OS X
comp.sys.mac.programmer.cocoa
Programming using the Cocoa APIs on Mac OS X
comp.sys.mac.programmer.xcode
Apple's Xcode development environment

I think the first point of concern that strikes me is that the use of
Carbon APIs from a majority-Cocoa program is fairly common and often
even recommended. It's not clear from the above separation (and proposed
charters I snipped) where messages reflecting that reality "should" be
posted. Given that Cocoa includes some procedure interfaces, I'm not
even sure a random relatively new developer could reliably identify
which library a certain routine came from.

The second thing that occurs to me is that I really haven't seen a whole
lot of discussion strictly about Xcode and question whether there's
enough traffic to justify a dedicated group.

G

[Tom Harrington]

Post by Simon Fraser
PROPOSED NEW GROUPS
comp.sys.mac.programmer.carbon
Programming using the Carbon APIs on Mac OS X
comp.sys.mac.programmer.cocoa
Programming using the Cocoa APIs on Mac OS X
comp.sys.mac.programmer.xcode
Apple's Xcode development environment

I'm with most of the other posts so far-- there's just not enough
traffic to justify adding more groups to the hierarchy. Absent some
reason to believe that the new groups would somehow attract new
participants, I can't see this as a good idea.