spaf@cs.purdue.EDU (Gene Spafford) (04/09/89)
Lots of interesting proposals have been made concerning how to decide
what groups to create/delete.
They don't really address the problem. We have not defined why we
want new groups or why we would want to delete old groups. Unless we
understand (and to some extent agree) on this, there will always be an
unrepresented group and/or an unhappy set of readers.
What we really need to do is define what Usenet is and where we want
it to go. If we have some common view then almost any sane, mature
group can guide (note that by that definition, netwide votes don't
work :-).
Usenet has grown largely by accident. A few times in the past, a set
of strong-willed individuals with a particular view of things has
helped guide the development, for good or bad. Examples would include
the structure of B news, the "great renaming," the creation of
news.announce.newusers, "kill" files, moderated groups, and some of
the special features of 2.11 news. I think my maintenance of the
"list of groups" is another example.
For a long time, there was a very small set of people with long
experience with the Usenet (and networking in general), and getting
them to reach consensus was possible. Now, with almost 1/4 million
readers of Usenet worldwide and 8 years of operation, we find the
group with expertise (and opinions) to be very much larger. Such a
large group cannot reach consensus...as evidenced by flame wars in
news.groups and the collapse of the old backbone group ("cabal" to the
sensationalist).
My view of history: The old "cabal" grew from a mailing list I started
in late 1984 when I first got concerned about the growth of
newsgroups and the problems with the namespace. I added admins
from sites I considered major, and persons who had evidenced a
calm, concerned attitude in the (equivalent of) news.* groups. The
list had under 3 dozen people. Out of that group came the idea for
moderated groups and a few other such goodies.
The "backbone" mailing list itself grew out of this "cabal" in
1985. We needed a name for the group, so I took Mark Horton's term
"backbone" and used that. After all, nearly everybody on the list
was an admin from one of the major sites. I put together a
description of what defined those sites (connectivity, stability,
current software, etc) and added people who weren't already on the
list but whose site met the criteria.
In 1986, a subset of that list met at the summer Usenix in Atlanta.
We brainstormed at a couple of meetings to see what could be done
to help improve the Usenet. News 2.11 was soon to be released and
it seemed like an opportune time to consider changes. Out of those
meetings came the "great renaming" and the current software to
handle moderated groups. The "checkgroups" control message was
also born at this time. (I seem to remember the following people
as being present: Mark Horton, Rick Adams, Mel Pleasant, Lindsay
Cleveland, Henry Spencer, Andrew Beals, Ron Heiby, Curtis Jackson,
Larry Auton, Tim Seaver, Chuq von Rospach, Erik Fair, Greg Woods
and me. There were at least 2 more, but I don't remember their
names -- can somebody else who was there remind me?)
As time went on, the "backbone" list grew (eventually reaching over
110). The group got involved in newsgroup wars after the "great
renaming" when people complained that we had forgotten their pet
newsgroups. Afterwards, when some newsgroup proposals appeared
for groups some (many) of us considered dangerous (viz., rec.drugs
and soc.sex), we decided by majority not to carry such groups.
Thereafter, people started pushing to create groups by whim, and
some made proposals just to annoy (viz.,
comp.protocols.tcp-ip.eniac). The group managed to reach
agreement on most of these, but flames from without, and diverging
views about the nature of Usenet within led to the eventual demise
of the group over the comp.women issue.
Now the above is a personal view of some history, and is therefore
subject to some coloration, but I think it captures the major points.
We needed some restructuring and guidance, and a large enough group
with extensive experience got together and filled the role. However,
differing views of what Usenet was, plus abuse and pressure from
agents of entropy led to the disbanding of the group. Those same
things will plague any new group unless the root causes are addressed.
And that, quite simply, is defining what Usenet is and where it is
headed. I think almost all of our current disputes can be traced to
this, including most of the battle over Brad's actions -- some people
don't share Brad's view of the Usenet.
Legislating the nature of Usenet as a set of rules will not work. We
need to (collectively) define, understand, and support "The Spirit of
Usenet" (whatever that may be -- if it even exists) and to educate new
users in that definition. Once that's understood, the rest is easy;
until then, any action will be like trying to herd cats.
Disclaimer: I seldom know what I'm talking about. Just ask my
students or my wife.
--
Gene Spafford
NSF/Purdue/U of Florida Software Engineering Research Center,
Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-2004
Internet: spaf@cs.purdue.edu uucp: ...!{decwrl,gatech,ucbvax}!purdue!spafchuq@Apple.COM (Chuq Von Rospach) (04/10/89)
>Such a >large group cannot reach consensus...as evidenced by flame wars in >news.groups and the collapse of the old backbone group ("cabal" to the >sensationalist). Just a further point of history. The term 'cabal' was coined by yours truly. Spaf's claim to it being sensationalist is definitely true, beacuse it was a term I used first during a time when various factions of the backbone and I were in disagreement over something or other (I think it was the 'great renaming'). Much like the once-popular 'net.fascist' it was designed specifically to describe how I then felt about the way the backbone was operating (to show how important these flamewars are in the long-term scheme of things, I no longer know who I was arguing with or what it was about. Think on that when you start the next "end of the net as we know it" argument: will you even remember what you were yelling about a year from now? Not likely....) Spaf's view is essentially how I remember it, also. My view is very similar to his as well. Everyone is running around and arguing semantics and nit-picking proposals (tha amount of silly side-bickering over my use of the term "he who pays the bills..." has been both amusing and eye-opening...). None of what I've seen has really tried to deal with the one reality of USENET -- that there is *no* way to develop a set of enforceable rules. What you *can* do is get a general agreement to abide by a set of parameters, as long as you don't then go and try to redefine the parameters out from under people -- Rick's suggestion is simple, straightforward, and as close to enforceable as anything I've seen. Everyone is so busy arguing the details that we aren't looking at the broad picture. What do we want? What is good for USENET? Everyone is so busy putting togehter rules, nobody bhas yet stopped to think if the rules make sense. I suggest that all this rule-making and vote-taking be put on the back burner while broader, more important questions get looked at. What is UESENET? What is USENET's focus? Why does it exist? Where should USENET be in a year? In five years? If you can come up with consensus definitions of these questions, what rules and procdures USENET need will fall out and become trivial to define. The problem with the ad-hoc rule-generation that we've been doing is that we keep reacting to given situations without really understanding what kind of result we want from a given rule -- we're big on "don't do this" but not very good at "this is what we want". Maybe if we try to plan USENET and stop being purely reactive things will get better. It certainly isn't working the current way... Chuq Von Rospach -*- Editor,OtherRealms -*- Member SFWA chuq@apple.com -*- CI$: 73317,635 -*- Delphi: CHUQ -*- Applelink: CHUQ [This is myself speaking. No company can control my thoughts.] USENET: N. A self-replicating phage engineered by the phone company to cause computers to spend large amounts of their owners budget on modem charges.
lmb7421@ultb.UUCP (L.M. Barstow) (04/11/89)
In article <6503@medusa.cs.purdue.edu> spaf@uther.cs.purdue.edu (Gene Spafford) writes: >Lots of interesting proposals have been made concerning how to decide >what groups to create/delete. > >They don't really address the problem. We have not defined why we >want new groups or why we would want to delete old groups. Unless we >understand (and to some extent agree) on this, there will always be an >unrepresented group and/or an unhappy set of readers. > > In 1986, a subset of that list met at the summer Usenix in Atlanta. > We brainstormed at a couple of meetings to see what could be done > to help improve the Usenet. News 2.11 was soon to be released and > it seemed like an opportune time to consider changes. Out of those > meetings came the "great renaming" and the current software to > handle moderated groups. The "checkgroups" control message was > also born at this time. Perhaps, then, it is once again time for a major rewrite of the news system. As I have not been on the net long (and am NOT by any means a UN*X wizard), I do not know entirely what this entails, however, there are a few things which could be incorporated into the news software... rmgroup could be made automatic (a control message of some sort could be easily inserted into the news packet format, I believe) to prevent problems of scattered sections of old dead groups. a similar group of control blocks could shift the addresses of moderated groups to new sites, etc.... as for the problem of defining reasons to want new groups, and how to go about counting these beasties, the current procedure is, if somewhat messy, a good start. Perhaps, as has been suggested over the past week or so, a moderated group called news.newgroup.votes could be created, the moderator being in charge of taking the votes and counting them (the moderator could take the votes by separating subject and summary lines eg...Subject: Re: sci.creation.koosh Summary: No being counted as a no vote for sci.creation.koosh) This would centralize all voting under one roof (whoever is "watching over" the net at the time). As for counts....it seems fairly obvious that, up to a certain point, it is easier to hold a conference via e-mail. For groups that receive only small numbers of votes, creation of a group is obviously , IMHO, stupid (to put it bluntly :-) I'll leave the definition of 'small' up to those who know what the net is capable of handling comfortably. Second, although this may seem a bit biased in favor of creation of newsgroups, I think it necessary that negative votes give valid reasoning for the non-creation of the group (ex I don't like the creator of the group doesn't quite cut it, although it MAY be a valid reason for asking for a new moderator on a moderated group. Similarly, the fact that the group is 90% covered in another group is obviously reason to think about not creating the group (unless, as a subdivision, it will cut down traffic, not promote cross-posting, and/or will cut out some unwanted discussion in the parent group...well, most everyone knows what the qualifications should be :-), I'm just stating the obvious because it seems that that MAY be necessary. A simple majority of 'Yes' votes vs weak 'No' votes should be sufficient to create the group, but a stronger (2/3, 3/4) majority should be considered if there are many valid 'No' reasons. Again, there is the possibility of another new group, news.newgroup.discussion (ack!) for discussing those controversial new groups. (I know this sounds like a lot of new news traffic, but it would clear the air of a lot of cross-posting and debates in parent groups.) Well, I've been long-winded enough... -- Les Barstow LMB7421@RITVAX.BITNET ...rutgers!rochester!ritcv!ultb!lmb7421.UUCP "I know you think you know what you thought I said, but you don't realize that what you thought I said was not what I meant"
bob@tinman.cis.ohio-state.edu (Bob Sutterfield) (04/11/89)
In article <647@ultb.UUCP> lmb7421@ultb.UUCP (L.M. Barstow) writes:
...rmgroup could be made automatic (a control message of some sort
could be easily inserted into the news packet format, I believe) to
prevent problems of scattered sections of old dead groups...
All control messages are, as you put it, automatic. newgroup and
rmgroup can be disallowed at each site, and reserved for root
intervention, at compile time. Recent patches of 2.11 enable them to
be allowed or disallowed at a distribution granularity. For example,
you could allow auto-{new,rm}group in alt.all only, but require root
intervention in all other distributions.
Scattered pockets of dead groups happen when people disallow automatic
rmgroups and don't keep up with them manually.
...a similar group of control blocks could shift the addresses of
moderated groups to new sites, etc....
This would be much harder to implement, and it seems that the current
mailpaths/"backbone" arrangement is working fine.chuq@Apple.COM (Chuq Von Rospach) (04/12/89)
> could be easily inserted into the news packet format, I believe) to > prevent problems of scattered sections of old dead groups... >All control messages are, as you put it, automatic. newgroup and >rmgroup can be disallowed at each site, and reserved for root >intervention, at compile time. For good reason. USENET is (surprise!) not a secure network, which is why rmgroups require administrator intervention. Do *you* really want to set up the system so that anyone with a basic knowledge of USENET can come in and delete your directory tree for you? You can't even safely set it up to only accept rmgroups from (say) Greg Woods -- because, as is shown every April Fools day, anyone can become Greg Woods in an untraceable way. Newgroups are not generally disabled simply because that's an additive function, not a desctructive function -- it's a lot easier to come in and repair the damage that a "newgroup ba.wobegon" does over the weekend than a "rmgroup comp.sys.unix.wizards" would do. Knowing the underlying structure of USENET, I'm not entire sure how you would build in a reasonable level of security into automating control messages. It would require some kind of public key encryption, and it would *still* be possible, with access to the source and one instance of the key, for a motivated person to forge out a usable control message. Besides, writing all that encryption code would be a major undertaking. Chuq Von Rospach -*- Editor,OtherRealms -*- Member SFWA chuq@apple.com -*- CI$: 73317,635 -*- Delphi: CHUQ -*- Applelink: CHUQ [This is myself speaking. No company can control my thoughts.] USENET: N. A self-replicating phage engineered by the phone company to cause computers to spend large amounts of their owners budget on modem charges.