🚀 go-pugleaf

Una Smith (smith-una@yale.edu) wrote:
> Since the bit.* hierarchy isn't part of Usenet proper, it isn't necessary
> to wait a month and then conduct a formal vote, is it?   There have been
> no dissenting voices on the issue of whether to create more natural
> newsgroup hierarchies.  So why not just do it, starting now, with any new
> gateway proposals?  Retroactive re-organization can be done bit by bit,
> as the groups themselves decide to organize themselves.

Amen.

> However, I think if we go ahead and do this, mainstream Usenetters will
> object that the bit.listserv.* hierarchy is already a place where lazy
> people can go to get around the not unreasonable Usenet group creation
> procedures, and now we're proposing to make it even more attractive to
> such people.  There is no question that this is a very real attraction
> for people who propose gateways.  Most gateway proposers are not "lazy",
> but rather extremely busy (as administrators of mailing lists, if for
> no other reason) and uncertain about the chance of passing a Usenet vote.

How can people who have already made the effort to establish a mailing
list and maintain it (much more work than I ever imagined) be considered
lazy?

> Valid reasons for going the bit.* route include:

I want to create a gateway for my mailing list for one simple reason.
When I lose a subscriber, their explanation is always the same: too much
mail in my mail box . . . gateway to network news.

I STILL must maintain the mailing list.  Several of my subscribers do not
have access to network news.

> Such mailing lists may well benefit from distribution via Usenet, but it
> is neither appropriate nor necessary that most Usenet sites get these
> groups, thus the bit.* hierarchy can serve as an academic hierarchy.

Sites don't need to keep the whole bit.* hierarchy anyway; they can
store only the specific groups in the hierarchy that they want.

> In this sense, many LISTSERV (and other) mailing lists such as student
> groups, cultural groups, and computer-related groups all belong in
> mainstream Usenet hierarchies, but topics such as Medieval texts may
> well fit best in the bit.* hierarchy.

I really don't think the subject matter is the key.

The existence of an active mailing list that needs a "window" through
network news is the important factor.

Jeff

--
Please send your response via email.  Thanks.

 Jeff Bowyer                         EMail: jbowyer@cis.vutbr.cz
 Computing Center
 Technical University of Brno
 Czech Republic

In <1tbn89INN7j9@MINERVA.CIS.YALE.EDU> smith-una@yale.edu (Una Smith) writes:
>Since the bit.* hierarchy isn't part of Usenet proper, it isn't necessary
>to wait a month and then conduct a formal vote, is it?   There have been
>no dissenting voices on the issue of whether to create more natural
>newsgroup hierarchies.  So why not just do it, starting now, with any new
>gateway proposals?  Retroactive re-organization can be done bit by bit,
>as the groups themselves decide to organize themselves.

Without objection, so ordered. New bit.** newsgroups will have names that
are more meaningful to their content and fall into general (but so far
undefined) hierarchies under bit.**.

People with existing groups can request that their names be changed and
this will be done as time permits.  The method used will be for the
owner to first post something to make sure everyone knows what's going
on.  This post should be cross posted to both the newsgroup being
changed and bit.admin.

If no significant objection is heard, a NEWGROUP control message will be
sent out for the new group. Two days later the gateway will be moved to
the new group. Two days after that a RMGROUP control message will be sent
out for the old group.

Does this sound like a reasonable way to go about it?

>However, I think if we go ahead and do this, mainstream Usenetters will
>object that the bit.listserv.* hierarchy is already a place where lazy
>people can go to get around the not unreasonable Usenet group creation
>procedures, and now we're proposing to make it even more attractive to
>such people.  There is no question that this is a very real attraction
>for people who propose gateways.  Most gateway proposers are not "lazy",
>but rather extremely busy (as administrators of mailing lists, if for
>no other reason) and uncertain about the chance of passing a Usenet vote.

Exactly. The bit.** hierarchy exists only to mirror mailing lists.

>Frankly, I think it may be time for some sort of procedure with respect
>to whether a gateway proposal should be accepted in the bit.* hierarchy,
>or should be directed to the appropriate Usenet hierarchy.  This need not
>be a voting procedure, merely a discussion.

The main reason I've seen for going bit.** now is:  "I want my group now
and I don't want to wait (for have to go through) the procedure to
establish a group in one of the traditional hierarchies."  The main
reason for going with a group in the traditional hierarchies is
propigation.

Jim McIntosh (jim@american.edu)
The American University
Washington, DC USA 20016-8019

In article <1tg6kaINNql3@au-ns.american.edu>, Jim McIntosh <jim@american.edu> writes:
> 
> If no significant objection is heard, a NEWGROUP control message will be
> sent out for the new group. Two days later the gateway will be moved to
> the new group. Two days after that a RMGROUP control message will be sent
> out for the old group.

I think your timeline is a little too compressed; On the USENET side both 
the NEWGROUP and RMGROUP messages may take a little time to propigate; May
I suggest that you issue the NEWGROUP and then send articles out cross-posted
to both the old and the new group for a period of time, then send out the
RMGROUP and finally after a second period remove the cross-post;

I would suggest that the cross-post occur for at least two weeks (and a month
is actually better) before issuing the RMGROUP. In USENET, when a group is
superceeded there will be a period of almost two months. 

I don't know if this is practical since you would have to handle the problem
of duplicates and the like but somehow you need to take into account the time
lag required for reorganizations to take place on the USENET side.
-- 
Richard H. Miller                 Email: rick@bcm.tmc.edu
Asst. Dir. for Technical Support  Voice: (713)798-3532
Baylor College of Medicine        US Mail: One Baylor Plaza, 302H
                                           Houston, Texas 77030

In <1tgloe$qlj@gazette.bcm.tmc.edu> rick@crick.ssctr.bcm.tmc.edu (Richard H. Miller) writes:
>I think your timeline is a little too compressed; On the USENET side both
>the NEWGROUP and RMGROUP messages may take a little time to propigate; May
>I suggest that you issue the NEWGROUP and then send articles out cross-posted
>to both the old and the new group for a period of time, then send out the
>RMGROUP and finally after a second period remove the cross-post;

Unfortunately the gateway code lets us post to one group or another.
I can move the gateway two weeks after setting up the new group and
then send out the RMGROUP two weeks later, but there is no facility
to cross-post to two groups at the same time.

Jim McIntosh
The American University
Washington DC USA 20016-8019

In article <1thhtkINN5p9@au-ns.american.edu>, Jim McIntosh <jim@american.edu> writes:
> 
> Unfortunately the gateway code lets us post to one group or another.
> I can move the gateway two weeks after setting up the new group and
> then send out the RMGROUP two weeks later, but there is no facility
> to cross-post to two groups at the same time.

 I think that would be fine. My primary concern was the propagation delay
for the USENET side. More and more sites are turning automatic NEWGROUPs
off so you need some lag time to allow the new groups to be created before
using them. The best is to cross-post to both, but I recognize the limitation
you are under.

However, if you have to reopen your gateway code, you might want to consider
putting in the capability to cross-post. 
-- 
Richard H. Miller                 Email: rick@bcm.tmc.edu
Asst. Dir. for Technical Support  Voice: (713)798-3532
Baylor College of Medicine        US Mail: One Baylor Plaza, 302H
                                           Houston, Texas 77030