Xref: utzoo news.groups:10948 news.admin:6284
Path: utzoo!utgpu!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: <296@ecijmm.UUCP>
Date: 18 Jul 89 03:37:20 GMT
References: <1528@stl.stc.co.uk> <3486@ncar.ucar.edu> <282@ecijmm.UUCP> <8670@cadnetix.COM> <3620@ncar.ucar.edu> <292@ecijmm.UUCP> <3677@ncar.ucar.edu>
Reply-To: jmm@ecijmm.UUCP (John Macdonald)
Organization: R. H. Lathwell Associates, Elegant Communications, Inc.
Lines: 169

In article <3677@ncar.ucar.edu> woods@handies.UCAR.EDU (Greg Woods) writes:
>In article <292@ecijmm.UUCP> jmm@ecijmm.UUCP (John Macdonald) writes:
>>There is no difficulty in removing a group - it is a simple control message.
>
>  Ah, if only that were the case... It is a "simple control message" that
>must be explicitly acted upon by every site administrator on the net.
>Not as simple as it looks.

Many sites are configured to act on such a message automatically.  Many others
will have site administrators that generally are up-to-date on news group
policies and would act on such a message fairly quickly.  Even if the previous
two groups only hit 30% of the network, it would disrupt distribution of the
group enough to effectively kill it.

In fact, 2% would do if it were the RIGHT 2% - start with uunet...  Does any
remnant of the backbone mailing list remain?

>>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.
>
>  Oh, yeah? I'll bet you 10:1 odds that if the group is still active when
>the "agreed-upon" time for expiration comes along, there will probably be
>more flames posted than the entire volume of the group up to that point if
>anyone attempts to remove the group. Were you around for the net.wobegon 
>debacle? Admittedly in that example there was never any agreement to remove
>the group ahead of time, but I'm willing to bet it won't make any difference.
>People will point to current activity and claim (rightly so) that the group
>is still needed.

Oh, of course, the fact that there is not much cause for objection has never
had much to with whether there is objection.  It would be a good idea to have
an automatic posting (perhaps bi-weekly) to each tmp newsgroup specifying
1. the current state of efforts to convert it to a permanent group, and
2. the automatic group cancellation time for each of the possible states

e.g.

    This group (tmp.example) is in the tmp news hierarchy and thus is
    under an absolute sentence of death.  If you believe that this group
    will still be serving a useful function at the end of its official
    lifetime (shown below), then get involved NOW with converting it to
    a permanent group.

    The current status of effort to convert this group to a permanent
    group is:
	DISCUSSION IN PROGRESS
    
    The remaining lifetime for this group is:
	Status				Appropriate Kill Date
	------				---------------------
	no discussion			already passed
	discussion in progress		1 week (Jul 24)
	vote in progress		5 weeks (Aug 24)
	vote completed			7 weeks (Sep 7)

>>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).
>
>  This is where we disagree; I don't think we NEED newsgroups for type (2)
>groups. For one thing how do we know the difference between (1) and (2)?
>That is what voting is supposed to determine! The proper way to deal with
>type (2) groups is to let them get voted into existence, but then have a 
>way to rmgroup inactive groups from the regular heirarchy. I think much of
>the opposition to the creation of new groups would go away if we could really
>count on getting rid of inactive groups.

Most of the time, the distinction between type 1 and 2 will be obvious.
The "New Coke" issue is a clear type 2 - there was no way to tell how long
it would last, but it would certainly die down eventually.  Chernobyl is
another type 2.  Cold fusion was a clear type 1 until we are able to apply
hindsight and realize that it was actually a type 2.  The difficulty in
determining when such a type 2 group has died down is definitely going to
cause problems, agreed.  Perhaps, a tmp.misc group could be used for the
remaining trickles of otherwise dried up type 2 groups.  This would mean
that people who are still using the group don't feel completely cut out.

>>I still see two topical categories - those that *will* fade, and those that
>>will not but are urgently needed.
>
>  But how do we know which is which? If it's really going to fade that
>quickly, what's wrong with discussing it in an existing group? If it isn't
>going to fade that quickly, readers of the related group in which the postings
>are appearing will be the first to vote YES for creating a permanent home
>for the topic.

Being wrong is not necessarily a problem.  If we incorrectly label something
type 1, then there is still the 2 to 4 month period in which it is being
converted to a permanent group to determine that it was a mistake and vote
down the permanent group.  If someone had started a vote for sci.fusion through
the normal voting process quickly enough, we might have had it officially
created as a permanent newsgroup just before it faded away.  As it is, there
was enough time wasted trying to bypass the normal voting process that it
didn't get created.  The tmp.* hierarchy might have affected this process
either way, in this instance - either a tmp group would have been created
quickly, and then a permanent group voted on as fast as possible (since
nobody would be kept busy fighting the system), or the tmp group would have
been created and during the leisurely conversion process, the need for it
disappeared before the vote completed.

>> }>>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.
>>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 real problem is that there is no way to determine ahead of time which
>is type (1) and which is type (2). If we made a distinction whereby one type
>has an enforced time limit and another does not, can't you already see the
>flame wars over which classification a given topic should get? This might 
>itself defeat the purpose of having tmp groups at all.

Yes, this is a difficult problem.  On the other hand, not providing an
extended duration tmp group for a clear type 2 discussion will ensure
that a permanent group gets created to handle the discussion that is
*clearly going to last beyond the 4 month deadline*.  It will not be
any easier to get rid of a permanent group than it is to get rid of an
faded tmp group.  How about the following for type 2 tmp groups - they
must have a normal vote at regular intervals.  They are eligible for
termination 4 months after the last successful vote to continue the group.
Thus, 2 1/2 months after a successful vote, the participants of the group
must organize another vote to continue it, if they feel that the purpose
of the group is going to extend beyond the 4 month limit.  As above, a
regular bi-weekly status message would help to focus the awareness of the
group participants upon their need to act to keep the group in operation.

>>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.
>
>   OK, just to show that I'm not just blindly disagreeing with everything you
>say, I can see the point here. In fact sci.physics.fusion is a good example
>of this.

Well, as I argued above, while sci.physics.fusion would have had considerably
less flamage if the tmp.* mechanism had been in place, it might have actually
been created in that less confrontational environment...

>>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.
>
>  This might be worth considering.
>
>--Greg

The fast vote would have to specify which set of rules it was intending to
abide by - type 1 or type 2.  In the borderline cases that weren't clearly
in either camp, the person suggesting the vote might be well advised to have
a brief discussion period before calling the vote to avoid getting too many
NO votes objecting that it should be the other type.  An alternative might
be to call for both votes simultaneously - voters could vote for one type
and against the other type if they had strong opinions about both forms,
could vote for (or against) one type and not vote either way on the other
type if they had no strong feelings about the second method they didn't favour,
or they could vote yes (or no) for both types if they didn't care about which
type it was.
-- 
John Macdonald