Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ucla-cs!dgreen
From: dgreen@CS.UCLA.EDU
Newsgroups: news.groups,news.misc,news.stargate,news.sysadmin,news.admin
Subject: Re: USENET Constitution
Message-ID: <7076@shemp.UCLA.EDU>
Date: Wed, 8-Jul-87 02:05:59 EDT
Article-I.D.: shemp.7076
Posted: Wed Jul  8 02:05:59 1987
Date-Received: Sat, 11-Jul-87 01:21:55 EDT
References: <266@brandx.rutgers.edu> <15982@gatech.gatech.edu> <6948@shemp.UCLA.EDU> <133@hippo.UUCP> <772@hao.UCAR.EDU>
Sender: root@CS.UCLA.EDU
Reply-To: dgreen@CS.UCLA.EDU (Dan R. Greening)
Followup-To: news.groups
Lines: 170
Keywords: Consitution, practicality
Xref: mnetor news.groups:1201 news.misc:722 news.stargate:240 news.sysadmin:290 news.admin:651

All followups to "news.groups" please.  Let's localize this discussion.

In article <772@hao.UCAR.EDU> woods@hao.UUCP (Greg Woods) writes:
>>In article <6948@shemp.UCLA.EDU>, dgreen@CS.UCLA.EDU writes:
>>> It really is time for a USENET constitution, or at least a set of clearly
>>> specified rules.


Greg has now flamed this idea three times.  My eyebrows are singed.

------------------  CONSTITUTION OBLIGATIONS? ------------------------

A viable USENET Constitution would not obligate a site to do anything.  
Indeed, like USENET itself, all sites always have the option of backing out:
either from backbone responsibility, or from receiving net news at all.

USENET has some unstated rules, even now, which if a site doesn't accept,
they have little choice but to leave the backbone cabal.  The big rule:  
if you can't carry the load, you can't be a backbone site.

Moreover, a viable USENET Constitution would not create a system much 
different from what we have now.  It would create accountability.  It 
would publicize a known structure.  The present structure is both 
unaccountable and unknown, but a structure exists nonetheless.

Public knowledge of the USENET structure helps it "make sense" to people.  
Readers would know who to talk to, and why things happen a particular way.

-----------------  WHAT IS KNOWN ABOUT THE CABAL  --------------------

This is what *I* know from asking some questions:

1. I don't know whether there is an exact written criteria stating how 
   one joins the "backbone cabal."  I know the cabal includes:

   a. Net administrators from sites well-connected to the rest of the 
      backbone, strategically located, and well-run by a responsive 
      network administrator who wants to be part of the backbone.

   b. Old backbone cabal people, who used to fall in the above category.

2. Technically, there are three semi-official spokespeople for the backbone
   cabal who monitor news.groups for newsgroup proposals, speak for the 
   backbone, etc.  Unfortunately, it appears that the associated 
   administrative burdens have fallen solely to Gene Spafford, who is not 
   one of the three, but does a good job.  

   Unfortunately, with one person doing the administrative part of this 
   job, periodic lapses were inevitable.

   Few people outside the backbone know who these "spokespeople" are.  
   They do not speak with "one voice," so what we see from backbone
   people can appear inconsistent.  Sometimes those comments are
   flame-ridden.  Both factors disturb people.

3. There is no stable "backbone chair"; someone who tries to bring the 
   backbone cabal to a consensus.  Some people have taken on that role,
   ad hoc.  

4. Some decisions are made at USENIX conferences, but are "ratified" by
   the backbone cabal since not every backbone site is represented at
   USENIX.

5. Most cabal decisions are made by e-mail; all decisions by consensus.

I know this because I offered to construct a draft USENET Constitution, 
and started asking Mark Horton questions.  Other backbone people I've 
asked haven't responded.  I don't get to watch it work, so this is all 
I know.  Sorry if I got some of it wrong.

Is there a place to find this information?  Not really.  One kind of USENET
Constitution simply formalizes what exists.  It makes the structure clear.

Few people anticipate a USENET revolution, so starting with a writeup of 
the existing structure makes perfect sense.

-------------------  A MUDDY RULE (GROUP CREATION)  --------------------

With a Constitution, we can keep "the rules" in one place, and clarify
those that are muddy.  For example, creation of newsgroups requires:

1. A vote of affected groups, requiring approximately 100 respondents with
   a clear majority desiring the new group.
2. The backbone cabal retains veto power.  Basically it vetoes any group 
   which might endanger the backbone status of any site.

We don't know for how long the poll must be taken (and polls have varied 
from 2 days to 3 weeks), whether there are prohibitions against stating 
PRO/CON opinions in poll announcements (most have included PRO opinions),
we don't really know how many people are required to start one (this also
varies widely).

We don't know how to kill an unused group (like soc.culture.something).

We don't know whether some "controversial" groups should be forced to be
moderated.  [Personally, I wonder why the backbone doesn't make moderation 
the RULE rather than the exception, through incentives or whatnot.]

--------------------  REPRESENTATIVE DEMOCRACY?  ----------------------

Suggested democratizing modifications to USENET:

1. Set up a moderated news.backbone newsgroup, within which backbone
   discussions occur.  Allow only backbone cabal members to post (made
   more secure by C news).

   Watching the backbone in action demystifies the backbone, and makes
   even the unofficial structure more clear.

2. Set up two parallel unmoderated/moderated newsgroups, called 
   news.structure where people discuss the USENET physical and political
   structure, and news.elections where elections are officially announced.

   Allow the backbone to call a poll on any idea it wants to, always in
   news.elections and presumably discussed beforehand in news.structure.

   Nothing makes it to news.elections without the prior approval of
   the backbone.  

3. Designate a backbone "chair" who would moderate news.backbone for 
   "external" postings from normal folks, and moderate news.elections.

4. Allow two members of the USENET population to run for one year 
   positions on the backbone cabal.  Candidates hash it out in 
   news.structure.  The election is announced in news.elections.  The
   backbone designates one of its members to count votes.  Votes are
   public, to ensure correct counting.

   This give "the people" a voice, but not much clout, in the cabal.

--------------------  RESPONSES TO GREG  -------------------------

>  I think the problem with this is that it is impossible to come up with
>a set of rules that could cover every possible situation.

Agreed, but this isn't a new problem.  No government has rules to address
every problem.  That isn't a reason to embrace anarchy.

> The bottom 
> line is, it is the responsibility and duty of the site admin to decide
> the policies of the net as they apply to his machine.

I don't exactly agree with this statement, for there are some accepted
things about being a backbone site that force a site administrator to
choose between remaining in the backbone or leaving, based on net policy.
For example, if seismo decided it was unwilling to carry 50% of the
USENET standard newsgroups, seismo would not remain in the backbone.
Any new seismo administrator would probably not be in the cabal.

On the other hand, day-to-day operation of an individual site is exactly
as you say.  Backbone sites have a little lee-way, but not as much as
non-backbone sites.

>Nothing changes.

This is NOT true.  USENET decisions have suffered from:

1. A lack of user knowledge of USENET structure.
2. A lack of diplomacy on the part of some backbone representatives.
3. A lack of input from accountable user representatives.  
4. A lack of guidelines for people who want to create a group.
5. A lack of accountability on the part of backbone representatives.
   (i.e., who ARE they?)
6. A lack of user respect for backbone members because of 1-5.

I think I've suggested ways to solve some of those problems.  


Dan Greening   Internet   dgreen@CS.UCLA.EDU
               UUCP       ..!{sdcrdcf,ihnp4,trwspp,ucbvax}!ucla-cs!dgreen