Splitting comp.lang.python

Paul Boddie paulb at infercor.no
Wed Mar 8 12:03:21 CET 2000

gerrit at nl.linux.org wrote:
> 4000 messages in 29 days is a lot. it's 138 messages a day. Previous
> discussions on splitting c.l.py always ended up in jokes and just
> disappeared; I want to resurrect an informal discussion on wheter
> to split the newsgroup or not; an RFD should be posted, of course,
> but IANAL: does anyone have time to create an RFD?
>     I propose to split c.l.py in a technical part and a non-technical part.

I think any proposal has to take into account the following factors:

  * How obvious it is to decide where to post messages. If you're a new user,
    is it obvious where to post your message? Consider that new users may do a
    quick, desperate search for a newsgroup and, given that their news feed
    may be unreliable or that they're doing a search for newsgroups on
    deja.com, find only comp.lang.python and not the hypothetical

  * How well the traffic is split between the new groups. Many suggestions
    have only shown how good people are at classifying topics rather than the
    suitability of those classifications. It might be possible to create a
    new group for each of the SIG topics, but how popular are each of those

  * How encompassing the topic of a particular group is. As I pointed out in
    an earlier message, it is not particularly desirable to have many groups
    where the majority of messages are cross-posted to other groups.
    Discussions tend to appear and disappear as people become tempted to "move"
    threads between groups.

  * Whether a group is really going to help people, or allow meaningful
    discussion to take place. Advocacy groups rarely allow either activity to
    go on.

One thing to remember is that as users become more technically competent, the
more likely it is that they will be able to subscribe to special interest
mailing lists and manage these interests appropriately. The issue here is
whether newsgroups are really necessary for such users or whether mailing lists
are enough.



More information about the Python-list mailing list