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!