Xref: utzoo news.groups:8397 news.admin:5253 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!unisoft!peritek!dig From: dig@peritek.UUCP (Dave Gotwisner) Newsgroups: news.groups,news.admin Subject: Re: Proposed OFFICIAL Newsgroup Creation/Deletion Guidelines Message-ID: <574@peritek.UUCP> Date: 25 Mar 89 02:13:03 GMT References: <1634@ncar.ucar.edu> <3088@alembic.UUCP> Organization: Peritek Corp., Oakland, CA Lines: 77 In article <3088@alembic.UUCP>, csu@alembic.UUCP (Dave Mack) writes: > In article <1634@ncar.ucar.edu> woods@ncar.UCAR.EDU (Greg Woods) writes: > [Rules for newsgroup creation - well-stated, no particular surprises.] > > > > RULES FOR DELETING A USENET GROUP > > > > I suggest that a reasonable basis for newsgroup removal would be that > the group has had fewer than some threshhold number of articles per > month (5-10?) for the preceding three months, as measured at three > "hub" sites (say rutgers, uunet and decwrl?) The hub sites must, of > course, carry the group in question over the measurement period. This > requirement would have to be met before the removal vote could be taken. > I read this as automated group removal or having a program determine when a group should be removed, and then start the discussion off. The problems that I have with this are the following: 1) What's to say a group might be idle for several month's and then become active again (there are some low volume groups right now that have nothing posted (or at least reaching my site) for one or two months, and then all of a sudden have 10-15 large items posted over the course of the next month, and then cycle back to 0 for one or two months). Add to this, the group volume may be a lot higher than the posting seems. In some groups, very little is posted, but lots of people (may) read the articles. 2) The net traffic for groups without much action would probably increase greatly around times for group removal... Namely, posting an article to start a discussion about removal, the people who read the group (see 1 above) posting articles to say no, prior to the vote, discussions based upon the original discussion but not having anything to do with the original call for discussion (for example, the whole set of discussions currently going on about R.H.F, which started as a discussion about a compilation copyright which was originally derived from the Brad/JDR interactions, etc). Also, add to this the net traffic (ie., mail, not news) when the actual vote gets called. Do this for every one of the groups which either someone or some program puts into a questionable volume catagory, and I can see a VAST increase in net volume (and not just short term, because as the number of groups on the net goes up, the number of groups which have low traffic may also go up). 3) It would only take one person to foul things up and force groups to remain (and skew the list of which groups are used and which aren't). A person could, have a program which might send out a small group of postings (3-4 a week) to his favorite low-volume group just to keep it around. Further, he could do this from several accounts on several different machines (given networks within companies), and noone would know that they weren't for real, without reading them. I recently had to remake inews on my system when the number of active groups was greater than the number that I originally made inews for. Other than that, the disk space occupied by empty directories is not great, nor are the number of inodes, etc. Groups which have nothing posted to them cause no real serious problems to occur (as far as I can tell) (other than eating up a little disk space and one inode per quiet group), that a backup-filesystem / remake-file-system (with larger ilist) / restore-filesystem or that a rmdir/mkdir wouldn't fix. The news that would be generated around removing a group would more than likely eat up more disk than having the empty group around (not to mention the eventual discussion to remake the same group again). I would suggest that we leave group removal up to the site administrators to determine which groups they don't want rather than do a blanket for the net as a whole. If space/inodes are a problem for some systems, they could manage the removal of the group on their system, rather than try something on a net-wide basis which may cause more problems than it would solve. -- ------------------------------------------------------------------------------ Dave Gotwisner UUCP: ...!unisoft!peritek!dig Peritek Corporation ...!vsi1!peritek!dig 5550 Redwood Road Oakland, CA 94619 Phone: 1-415-531-6500