tneff@well.UUCP (Tom Neff) (04/06/89)
I really think this whole issue of newsgroup creation has gotten out of
hand. Usenet seems to work best as a participatory anarchy. Votes,
advisory boards, cabals (Qabbalahim? <grin>) are all steps in the
wrong direction. Let the marketplace of ideas (and the individual
willingness of site admins to carry things) decide which groups
deserve to exist.
I would abolish the current voting system entirely and let any site
admin issue a newgroup any time they feel like it. In addition I
would add just two things:
* Moderate news.groups. Restrict its content to newgroup
and rmgroup proposals, and serious followup discussions.
The moderator should reject flames.
* Solicit volunteer help every so often to go out and prune
dead limbs from the Usenet tree based on Arbitron
propagation and readership information.
The "guidelines" would consist of a gentle request to do the following:
* Post a proposal in news.groups before issuing a newgroup.
Invite feedback via mail or (if mail bounces) posting.
This should give the proposer and other interested netters
a chance to see how popular the idea is.
* Include a copy of the proposal in the newgroup message
when and if you send it. This lets admins who missed
the proposal in news.groups make an informed decision
before turning on the faucet.
* Site admins - read all these control messages carefully and
exercise your own judgment before enaabling a group.
Leave rmgroup'ing to the periodic volunteer pruning squad.
--
Tom Neff tneff@well.UUCP
or tneff@dasys1.UUCPchuq@Apple.COM (Chuq Von Rospach) (04/06/89)
>I would abolish the current voting system entirely and let any site >admin issue a newgroup any time they feel like it. Down that road lies chaos. Look at alt.* as an analog. While alt works quite well (and is significantly smaller than USENET) in most cases, there have been a number of specious groups created and numerous rmgroup wars over the last few years. Scale it up to USENET and I wouldn't want to see the results. > * Moderate news.groups. Restrict its content to newgroup > and rmgroup proposals, and serious followup discussions. > The moderator should reject flames. If we adopt your previous suggestion, the first thing that would happen would be the creation o net.groups.unmoderated, and nothing would change. Either that or people would start sending out newgroup messages to unmoderate news.groups again out from under you. If you don't enforce some kind of control over group creation, you lose all protection for moderated groups, because anyone can then pop in and unmoderated it. Which is a great reason to keep control over group creation, if you think about it. Chuq Von Rospach -*- Editor,OtherRealms -*- Member SFWA chuq@apple.com -*- CI$: 73317,635 -*- Delphi: CHUQ -*- Applelink: CHUQ [This is myself speaking. No company can control my thoughts.] USENET: N. A self-replicating phage engineered by the phone company to cause computers to spend large amounts of their owners budget on modem charges.
tneff@well.UUCP (Tom Neff) (04/08/89)
In article <28488@apple.Apple.COM> chuq@Apple.COM (Chuq Von Rospach) writes: >[Neff writes] >>I would abolish the current voting system entirely and let any site >>admin issue a newgroup any time they feel like it. >Down that road lies chaos. Look at alt.* as an analog. While alt works quite >well (and is significantly smaller than USENET) in most cases, there have >been a number of specious groups created and numerous rmgroup wars over the >last few years. Scale it up to USENET and I wouldn't want to see the >results. Chuq is making me face reality, which I absolutely HATE! :-) Unfortunately it's as easy to rmgroup something or un-moderate it (two actions with real potential to annoy the net) as it is to create a new group (which I would argue is far less annoying and a Good Thing overall). This is already true today, but conventions of good behavior prevent anarchy. Chuq suggests that if we adopted a "newgroup at will" philosophy, the rest of the alt.* shennanigans would ensue automatically. I am not sure if I agree completely here -- surely some of the rmgroup war mindset is due to the "playpen" aura alt.* seems to cultivate? I guess there's plenty of room to disagree on this one. >[he points out that moderating news.groups conflicts with the first > goal and would cause more anarchy] >Which is a great reason to keep control over group creation, if you think >about it. There is an automated solution if you want to build it. Create a newsgroup list maintainer at one major site. Let it collect votes continuously for any proposed newsgroup's creation, removal or status change. Votes would be EXPIRED, WEIGHTED and COUNTED daily and appropriate action taken. EXPIRING would consist of discarding everything over a month old, simple enough. WEIGHTING would be complex but rewarding. Someone sits down and creates a formula that takes Usenet map and/or arbitron data into account and weights each site's vote so that sites which (a) feed lots of people downstream and/or (b) call a long way to get stuff would count for more than that don't. I couldn't begin to list all the variables worth considering, but it would be fun to come up with something. When the weighted count reached an action point the maintainer site would automatically issue the newgroup or whatever, as well as notify folks in news.groups. As a fun added frill, perhaps you could mail to vote-check@maintain to find out the current status of an ongoing vote. Then let all well connected sites (and anyone else careful enough to keep their patch level up) change the news software to accept newgroup and rmgroup messages for the major hierarchies ONLY from the list maintainer site. If some leaf rmgroups sci.misc for jollies it wouldn't propagate. However if nj.toxic.dumps goes moderated that's their business. -- Tom Neff tneff@well.UUCP or tneff@dasys1.UUCP
chuq@Apple.COM (Chuq Von Rospach) (04/08/89)
>Unfortunately it's as easy to rmgroup something or un-moderate it (two >actions with real potential to annoy the net) as it is to create a new >group (which I would argue is far less annoying and a Good Thing >overall). No, it's not. Rmgroup messages are trapped by code in USENET (unless specifically turned off at compile time). A rmgroup doesn't happen -- it sends mail to the admin telling him to go and rmgroup it. And the reality is, many of them don't bother. There are still sites here in the bay area that have ba.wobegon around, which was an offshoot of a little disagreement Gordon Moffett and I had four or five years ago. The reality is, you create a group, it gets created. You send out a rmgroup, maybe it gets deleted, maybe it doesn't -- and then you end up with a bunch of disconnected pockets of sites where people are posting into a group that doesn't exist and wondering why nobody is answering. That creates a rather nasty form of confusion, especially for the naive user -- they think they're dealing with a 'real' gropu and 'getting out' when they really aren't. Not a good thing at all. This is the only real reason why I'm against newsgroup creation on demand these days -- because a group, once created, basically exists forever no matter how many rmgroups go out. The concept of a tem.all is nice in theory, but the mechanics of the net keep it from working right. This is, by the way, about the fourth or fifth time I've seen this discussion come up -- once pre-Cabal, twice in the Cabal, and now. After looking at it closely each time, it's always been found to be nice but unworkable. Sigh. Moderated groups are another issue, but there are problems there, too. I found out, much to my dismay, that it's impossible to cleanly turn a moderated gropu unmoderated -- too many sites either never see the control messages or ignore them. When we turned comp.text.desktop unmoderated, I spent a couple of weeks getting literally *hundreds* of copies of each posted message mailed to me by nice sites that thought comp.text.desktop was still moderated. I finally have to start dumping things wholesale to /dev/null just to keep from filling up disks... Here's a case wehre the mechanism *does* exist, but it's unreliable enough that it might as well not be there. (Sort of like message cancellation, another existing mechanism that never quite seems to work right). >This is already true today, but conventions of good behavior prevent >anarchy. Chuq suggests that if we adopted a "newgroup at will" >philosophy, the rest of the alt.* shennanigans would ensue >automatically. I am not sure if I agree completely here -- surely some >of the rmgroup war mindset is due to the "playpen" aura alt.* seems to >cultivate? The reason I say that is this: the same people playing with alt.* are here on USENET. If you adopt alt.*'s format on the rest of USENET, with the same people who are fooling around with it over there over here, how can you not believe that they'll jjust bring their games over here as well? I'd be surprised as all get out if it didn't happen. Chuq Von Rospach -*- Editor,OtherRealms -*- Member SFWA chuq@apple.com -*- CI$: 73317,635 -*- Delphi: CHUQ -*- Applelink: CHUQ [This is myself speaking. No company can control my thoughts.] USENET: N. A self-replicating phage engineered by the phone company to cause computers to spend large amounts of their owners budget on modem charges.
RWC102@PSUVM (R. W. F. Clark) (04/09/89)
In <11269@well.UUCP> tneff@well.UUCP (Tom Neff) writes:
[An excellent proposal for newroups involving
centralizing the group creation authority.]
It might also be a good idea to moderate news.groups
to limit it to calls for votes, creating an unmoderated
discussion group to avoid the extremely low SNR of
news.groups.
It might be possible to weed out the more silly newsgroup
proposals at the moderator level, or to allow the moderator
to ensure that newsgroup name proposals are correct, to
avoid groups created in inappropriate hierarchies.
However, it might be best to avoid giving the moderator
veto power to avoid newsgroups being scuttled before
discussion because the moderator doesn't like them.
It would also be very easy to enforce the two weeks' discussion
rule, ensure the validity of votes, avoid duplication and prevent
votes being lost due to poorly-connected vote-collectors.
fc