Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/17/84 chuqui version 1.7 9/23/84; site nsc.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!ihnp4!nsc!chuqui
From: chuqui@nsc.UUCP (Chuq Von Rospach)
Newsgroups: net.news
Subject: Re: It's time for news to get user-UNfriendly
Message-ID: <2451@nsc.UUCP>
Date: Sat, 9-Mar-85 02:57:39 EST
Article-I.D.: nsc.2451
Posted: Sat Mar  9 02:57:39 1985
Date-Received: Sun, 10-Mar-85 05:36:44 EST
References: <245@looking.UUCP>
Reply-To: chuqui@nsc.UUCP (Chuq Von Rospach)
Organization: The Village
Lines: 138
Summary: 

In article <245@looking.UUCP> brad@looking.UUCP (Brad Templeton) writes:
>It's a hard fact to take, but the time has come to be autocratic and
>start enforcing netiquette in software.  Past authors of the news softare
>have made the (understandable) mistake of trying to make the posting software
>easy to use.  This should be stopped.

Brad and I have been disagreeing on this point in private-- now it seems to
be time to disagree in public. 

Attempting to solve the news problems by making it harder to use works just
as well as making cars less likely to kill someone by flattening the tires.
It works, but it doesn't increase the usefulness of the tools and it only
works until someone patches it.

To continue with the automobile analogy (and hopefully not stretch it too
far) if you want to reduce the number of automobile deaths you have to do
one of two things-- make them less likely to crash or make them more likely
to have their occupants survive. Also like automobiles there will be large
numbers of automobiles that already exist that won't be upgraded to these
new standards of safety, and there will be a significant percentage of
those that subvert the laws (18% of cars supposed to use unleaded are
illegally fueled with leaded fuel) and a good percentage that would simply
hack out the changes they don't like (catalytic converters, for example). 

So much for stretching a point, but the analogy holds-- any software
changes we install take a LONG time to propogate, if they propogate at all.
People who don't like those changes simply won't install them or will
remove them. 

If a car needs a tuneup, it won't perform as optimally as it should. But if
you flatten the tires to solve engine knocking at high speeds, you don't
solve the problem. Usenet needs a tuneup. (I know, I said I'd drop the
analogy...)

This doesn't mean that what Brad says is useless, but I think we need to be
looking for ways for reducing the number of 'crashes' and also make it
easier to survive these 'crashes'. (the analogy is now officially DOA)

>1) No "Re:" lines on followups.   News should not provide an automatic subject,
>   and instead should require a new AND DIFFERENT subject to be entered.
>   If an article is new, it talks about something new, and the subject should
>   say what this is.  While we're at it, no subject should be less than about
>   50 characters.    Detecting grouped articles is not a function of the subject
>   but rather of the References lines

All this does is increase hassle factors for the poster, not increase the
available information. Not all systems support the References line (for
instance, Dec's Enet, most notes systems, and everything coming off of
arpa. This means that Reference lines show up on probably no more than 50%
of the volume of the net, and none of the areas that don't support it can
be fixed by updating the news software (or really have a reason to upgrade
for this feature within their sphere of reference).

>2) No included text of the source article.  In fact, the software should
>   detect articles with included text and reject them.

Included text has a purpose, but it needs to be edited to the neccessary
abstracts. I now wish it hadn't been made so easy to include text, because
it is terribly misused, but I dont see an easy way to remove the feature
from future releases. Chip Rosenthal is working on postnews, and 2.10.3
will probably be making checks of followups and restrict total percentage
of a followup to some percentage of the size of the article.

>3) No immediate followups.  Instead, all followup requests should be collected
>   and batched to the end of the news session
rn already allows this, and I use it continuously (put articles away with
the 'M' command, then re-enter the newsgroup after you finish it. A lot of
the time you find you don't NEED to post a followup, because someone else
has and it is waiting to be read-- subject searches in rn also make this
easier to see). 

>4) Default distribution region-wide (or smaller)
I don't know about this-- It sounds good, but there are implications that
need to be thought through. Should Unix-wizards be regionalized?

>5) Default followup done as mail to the sender, and only a later question
>   after the article is prepared allowing the article to go to the net.
Postnews and followups probably ought to remind users a little more
stridently to use mail-- people OUGHT to be more careful about using mail.
(A good example-- after my first posting on this whole subject, I've gotten
well over 100K of private mail on the thing-- I'm VERY glad I asked people
to send it as mail, since most of it doesn't need to be seen by everyone,
but the important parts end up influencing future comments on my part.

>6) Detection of beginning users, and beefing up the verbosity and restriction
>   for them.  Moderating them if need be.
How do we detect them? Who moderates them? The site administrator? the same
site administrator who we can't get to upgrade to 2.10.2 due to lack of
time? right.

>6) K news (of course)  A thousand keywords, and a good 5 minutes of research
There are two number sixes... (six of one, half a dozen of another?) I've
looked at keywords, and I'm not convinced that they are nearly as wonderful
a solution as others. I've put up some quick&dirty prototypes, and there
are technical issues I can't see easy answers for, as well as finding it at
least as difficult (or maybe more difficult) to find things with keywords.
I'm not saying it is a bad idea, just not a simple solution-- it solves
some things, but creates a whole net set of problems that need to be dealt
with. Keywords may well be a solution, if we can find a way to integrate
them into the existing net, but people should be aware that they aren't a
panacea. How many users would REALLY be willing to spend five minutes
trudging through lists of keywords, anyway? wouldn't it be better to allow
users to simply generate their own keywords? Wouldn't it be better to get
that user to spend 5 minutes reading emily post and whatever other
documents help them understand the net better? (serious questions-- not
flippant ones-- please mail me your opinions...)

>So this all sounds nasty and restrictive?  Will it make posting a pain?
>GOOD.
Bad! In an environment that has no way of enforcing changes, the places
where the changes are needed most become least likely to install them. 

>Of course, these changes, along with many other things like K news will
>never get done, since nobody has the time and nobody wants to pay for
>Usenet, Inc.

Which is why I'm looking for administrative fixes-- things that can be done
without software development costs and time, without changes to existing
sites, and can be done within the current nature of the net. The two that
look most promising are significant rewrites of parts of the documentation
set similar to my emily post rewrite of last year (and making that
documentation more visible on the net, somehow) and cleaning up the naming
space. Both can be done from what little 'central' authority there is,
doesn't require software changes, and can make a difference, quickly and
cheaply. My mail shows that people seem to be ready for some of these
changes, and I'm willing to work on doing them as long as the net does seem
to support them, but I want them to be what the network wants, and I want
them to make things better. To do that, I need feedback from the net on
what directions you think the net should be moving. I'll have more details
on this later, but please drop me a line and give me an idea of what to
look for.

chuq
-- 
Chuq Von Rospach, National Semiconductor
{cbosgd,fortune,hplabs,ihnp4,seismo}!nsc!chuqui   nsc!chuqui@decwrl.ARPA

Be seeing you!