Xref: utzoo news.groups:10718 news.admin:6212
Path: utzoo!attcan!lsuc!ecicrl!ecijmm!jmm
From: jmm@ecijmm.UUCP (John Macdonald)
Newsgroups: news.groups,news.admin
Subject: Re: tmp.* hierarchy (was: moderated "newsgroups" group)
Message-ID: <292@ecijmm.UUCP>
Date: 8 Jul 89 04:00:26 GMT
References: <1528@stl.stc.co.uk> <3486@ncar.ucar.edu> <282@ecijmm.UUCP> <8670@cadnetix.COM> <3620@ncar.ucar.edu>
Reply-To: jmm@ecijmm.UUCP (John Macdonald)
Organization: R. H. Lathwell Associates, Elegant Communications, Inc.
Lines: 158

In article <3620@ncar.ucar.edu> woods@handies.UCAR.EDU (Greg Woods) writes:
 }In article <8670@cadnetix.COM> rusty@cadnetix.COM (Rusty Carruth) writes:
 }>In article <282@ecijmm.UUCP> jmm@ecijmm.UUCP (John Macdonald) writes:
 }>...
 }>>  Why not
 }>>set up an alternate newsgroup called tmp?...
 }>
 }>I like it!
 }
 }  At first, I didn't like this idea because of the difficulty of removing
 }groups in practice. I still think that difficulty will somehow need to be
 }addressed before a tmp heirarchy could work.

There is no difficulty in removing a group - it is a simple control message.
When part of the official charter of any tmp group is an explicit time
limit, then there is not much cause for anyone to object when a rmgroup is
done at the appropriate time.  The main problem may be seeing 200 different
rmgroup messages all bouncing around the entire network on X-day as 200
system administrators get a chance to be backboner-for-a-day.

 }                                              But I do like the idea of being
 }able to create groups KNOWING that they WILL be removed after a known, fixed
 }amount of time. A lot of flame wars (and crap that I get in the mail) such
 }as resulted from something like sci.physics.fakery (oops, I mean 
 }sci.physics.fusion! :-) could be eliminated.

Exactly what I felt.

 }   What I envision "tmp" could be used for is a place to have topical
 }discussions while a vote is held on a permanent home for the topic.

That's sort of a cross between the two different possibilities I
originally suggested (1) urgently needed groups which are "certain"
to eventually get a permanent home and which are disrupting discussion
elsewhere, and (2) known temporary topical discussions which are certain
to never need a permanent home (but for which it may be difficult to come
up with a good time limit a priori).

 }                                                                    What I
 }*don't* want to see it used for is creating groups that fail to pass a
 }vote,

Agreed.

 }      or just to get around the normal time it takes to go through the
 }"official" group creation procedure.

I don't mind this in exceptional cases, but it should not be the rule.

 }                                     That is what the "alt" heirarchy is for.
 }It should be restricted to TOPICAL subjects, where the discussion might be 
 }severely impacted by a long delay in getting it started. As an example, 
 }sci.physics.fusion was topical, rec.music.dylan isn't.

I still see two topical categories - those that *will* fade, and those that
will not but are urgently needed.

 }>> category two with vague termination criteria could lead
 }>>to flames and bad feelings if a group is removed when some people don't
 }>>agree that it has outlived its charter.  
 }
 }   This is easily fixed, by setting a date ahead of time when the group will
 }be deleted. A time limit that will apply to ALL groups created under tmp.
 }No flames, no arguments. The group proponents would have that long to get
 }a group created in the "official" heirarchy. If this attempt fails either the
 }group gets created in "alt" or disappears altogether.

This works fine for type (1) groups - either they fulfilled their promise
and a regular group has been established, or they have not and thereby
have failed.  However, it is not so easy with type (2).  The "classic"
example is New Coke.  If it had been created as a tmp group with a two
month charter, there would have been a huge uproar if it got deleted
a week before Coka-Cola capitulated and re-introduced Coke Classic.
(The timing may be off here, but in some future short term group, such
a timing may come to pass.)  I would suggest that there be a fairly
large time limit on type (2) groups unless there is a known-in-advance
time limit (my previous example of the Olympics).  Perhaps nine months
would be about right - if it is still vigourous after seven months, then
people could decide to try and make it a permanent group despite its
apparent temporary nature.

 }>
 }>How about an absolute maximum life of 6 months or a year?  
 }
 }   OK, let's see: an official group creation, according to the creation
 }guidelines, takes from 49 to 65 days (14-30 days discussion, 30 days voting,
 }5 days vote verification). So, I think that 65 days is a reasonable maximum,
 }with creation of a tmp group being an automatic call for discussion on the
 }creation of a permanent group for that topic (note that a call for discussion
 }does not necessarily lead to a vote being held or a group being created; it
 }may be that there are some topical subjects that will really be of only
 }passing interest). This allows enough time to go through the official creation
 }process before the tmp group is removed, but NOT enough time so that groups
 }that fail to go through the creation process can hang around forever.

I suggested four months for groups that are expected to become permanent.
This allows some time for the tmp group to operate and be observed before
a vote is forced.  If there is a demonstrable lack of volume after a month
and a half, then that later might fail, where an earlier vote would have
possibly succeeded.

 }>When the
 }>expiration date comes around, if there is still enough interest then
 }>it would be time to discuss it in n.g and vote on making a permanent 
 }>place in the permanent space.
 }   
 }   This ought to be done BEFORE the expire time comes around. Expiring a
 }group will never work unless it can be done according to rigid rules that
 }the site admins on the net have voluntarily agreed to follow and which cannot
 }be argued with (which means they need to be SIMPLE).

Agreed - my four month period was chosen to allow an observation period, a
discussion period, a vote, and creation time in a non-hurried fashion to
occur *before* the tmp group was scheduled to die, with earlier cutoff
if the creation attempt had clearly bogged down.

 }>As far as 'what makes a group urgent' 
 }
 } That is, of course, the rub.

How about an amplification of Rusty Carruth's suggestion.  I would suggest
that we allow a special fast vote for tmp groups.  It could take place
without discussion before the call to vote, and require 50 more yes than no
votes in ten days, or 75 more yes than no votes earlier to cut it even shorter.

 }                              In order for tmp to work, I think the following
 }things need to be addressed (obvious, but at least openly stated here):
 }
 }1) We have to make sure that tmp groups really do expire and don't hang around
 }   indefinitely. 

Agreed.

 }2) We have to come up with a way of defining what is "topical". I don't see
 }   any really good way of doing this other than empowering one person or small
 }   group of persons to decide this. (I am not volunteering myself for this;
 }   I will already have enough to do with the group creation process if I 
 }   become moderator of news.announce.newgroups which is currently being voted
 }   on) It needs to be something that will limit the number of groups that live 
 }   under tmp at any one time; if the tmp namespace gets too cluttered, it 
 }   loses its usefulness.

An alternative is the fast vote suggested above.

 }3) We have to come up with a set of definitions that will encourage every site
 }   that carries sci, comp, etc. to also carry tmp. Otherwise we've just got
 }   another alt and why bother with tmp, just create the topical groups under
 }   alt as now happens.

Agreed.  I think we're well on the way to doing just that.  Just imagine,
no more "we need it now" flames, that should reduce news.groups volume by
10% or more.

 }--Greg


-- 
John Macdonald