pedz@bobkat.UUCP (05/15/87)
I would like people posting programs to the net to describe briefly
what they do at the top of the article. Not a complete detailed
description but at least something that lets me know what they are
suppose to do. For example there is a program just posted called
filter. There is absolutely no comments at all about what it does or
how to use it. This is really really really really really stupid. If
you want people to use your software, you should at least let them
know what it is.
This espeically applies to the moderated groups. You get titles like
FROB and a comment at the start of the first article that says ``This
is FROB version 2.5''. Inadequate! I have better things to do then
to keep track of all of the programs in the world and all of their
names. Not to mention the problem of the same name being used in more
than one program. The name of the program does not describe it.
On to the second wish of mine. I would like all articles for
the same program to be responses to the first article. This way, I
can hit ``k'' only once and get past ten or so files which do not
interest me. I am sure that this would make the notes users much
happier as well.
On a different subject and not related to sources is my wish for
everyone who responds to an article to post it as a response, do not
change the title, and keep all of the appropriate info in the header
to make it look like a response. Frequently I have to resort to the
kill file technique just to get around something that the k key could
and should solve if everyone cooperated. Do not think that your two
cents on a subject is completely revolutionary and requires a whole
new base article even if the subject has drifted off the original
topic.
There, I didn't say #$&@ once.
--
Cute signature line employing many literary allusions and puns.
Standard disclaimer concerning my mental incompetance.
Perry Smith a.k.a. (Pedz Thing)
pedz@bobkat or {ti-csl,infotel}!pollux!bobkat!pedzrsweeney@dasys1.UUCP (05/18/87)
In article <969@bobkat.UUCP> pedz@bobkat.UUCP (Pedz Thing) writes: >On a different subject and not related to sources is my wish for >everyone who responds to an article to post it as a response, do not >change the title, and keep all of the appropriate info in the header >to make it look like a response. Frequently I have to resort to the >kill file technique just to get around something that the k key could >and should solve if everyone cooperated. Do not think that your two >cents on a subject is completely revolutionary and requires a whole >new base article even if the subject has drifted off the original >topic. >Perry Smith a.k.a. (Pedz Thing) Something like this would please me in particular. I'm trying to come up with a decent way to handle message threading in a conferencing system I'm developing, and something like this would make my task extremely simple. On most traditional-format BBS systems, the subject line is not edit-able, which means that a thread could logically be developed simply by linking together messages with the same subject. Since subject lines in netnews articles can be edited, this capability is impossible. How about introducing an item into the message header called a conversation code (or something to that effect). It need not be displayed when you read the message - it's for "internal use only." A code is generated when a message is posted that does not refer in any way to a previous message. All subsequent followups and such are given the same conversation code. The "k" and associated commands would seek out and junk articles bearing the same code, rather than using the unreliable subject field. -- Robert Sweeney ..!cmcl2!phri!dasys1!rsweeney Big Electric Cat Public Access Unix - System Operator Line noise can kill.
mcb@lll-tis.UUCP (Michael C. Berch) (05/18/87)
In article <969@bobkat.UUCP> pedz@bobkat.UUCP (Pedz Thing) writes: > . . . > On a different subject and not related to sources is my wish for > everyone who responds to an article to post it as a response, do not > change the title, and keep all of the appropriate info in the header > to make it look like a response. Frequently I have to resort to the > kill file technique just to get around something that the k key could > and should solve if everyone cooperated. Do not think that your two > cents on a subject is completely revolutionary and requires a whole > new base article even if the subject has drifted off the original > topic. This is self-contradictory -- if the subject has "drifted off the original topic", it SHOULDN'T be killed by the rn 'k' command. It is a new topic. That is why I usually make sure to change the subject line (retaining "Re:" as directed by RFC850; see below) when responding to exchanges where the either the subject has already changed, or my own article changes it. The question is not whether someone's two cents is "revolutionary" -- it's whether it's on a new topic or not. It is considered desirable to have subject lines accurately reflect the content of articles; remember, not everyone came in at the beginning of the discussion. The idea that subject lines should both indicate that they are a reply to an article and disclose the actual subject is from RFC850, which says: From Mark R. Horton, Standard for Interchange of USENET Messages (RFC 850, June 1983) [. . .] 2.1.6 Subject The Subject line (formerly "Title") tells what the article is about. It should be suggestive enough of the contents of the article to enable a reader to make a decision whether to read the article based on the subject alone. If the article is submitted in response to another article (e.g., is a "followup") the default subject should begin with the four characters "Re: " and the References line is required. (The user might wish to edit the subject of the followup, but the default should begin with "Re: ".) Thus given an original article Subject: University support of UNIX Message-ID: <123@foo.bar.org> a reply on that topic might contain Subject: Re: University support of UNIX Message-ID: <456@frob.com> References: <123@foo.bar.org> while a followup on a tangential topic might contain Subject: Re: 4.3BSD licensing agreement Message-ID: <789@gargle.blat.edu> References: <123@foo.bar.org> The interface software can then identify the last of these as a reply to the original article by noting the "Re: " and examining the References line, if it so chooses. Everybody got that? Michael C. Berch ARPA: mcb@lll-tis-b.arpa UUCP: {ames,ihnp4,lll-crg,lll-lcc,mordor}!lll-tis!mcb
jerry@oliveb.UUCP (Jerry F Aguirre) (05/21/87)
In article <419@dasys1.UUCP> rsweeney@dasys1.UUCP (Robert Sweeney) writes: >How about introducing an item into the message header called a conversation >code (or something to that effect). It need not be displayed when you read >the message - it's for "internal use only." A code is generated when a >message is posted that does not refer in any way to a previous message. >All subsequent followups and such are given the same conversation code. The >"k" and associated commands would seek out and junk articles bearing the >same code, rather than using the unreliable subject field. How about using the message ID and references header lines which already provide this information. When a followup article is posted the "Refferences:" header line contains the message IDs of the parent articles. No harder to look for than comparing subjects or a "conversation code".
andytoy@watdcsu.UUCP (05/21/87)
In article <419@dasys1.UUCP> rsweeney@dasys1.UUCP (Robert Sweeney) writes: |In article <969@bobkat.UUCP> pedz@bobkat.UUCP (Pedz Thing) writes: |>everyone who responds to an article to post it as a response, do not |>change the title, and keep all of the appropriate info in the header |>to make it look like a response. Frequently I have to resort to the |>kill file technique just to get around something that the k key could |>and should solve if everyone cooperated. Do not think that your two |>cents on a subject is completely revolutionary and requires a whole |>new base article even if the subject has drifted off the original |>topic. | |How about introducing an item into the message header called a conversation |code (or something to that effect). It need not be displayed when you read |the message - it's for "internal use only." A code is generated when a |message is posted that does not refer in any way to a previous message. |All subsequent followups and such are given the same conversation code. The |"k" and associated commands would seek out and junk articles bearing the |same code, rather than using the unreliable subject field. First of all I think that the subject should reflect the contents of the article and that the Subject field should be edited in such a way as to include the original subject as well as the current topic of discussion (i.e. "Subject: something new (was nothing new)). Maybe there should be an "Original-Subject:" field so that "kill" will work on that instead of the "Subject:" field. Personally, it doesn't bother me to press 'k' an extra time when I come across an article about an old subject, but with a new subject line. -- Andy Toy, Department of Computing Services (DCS), University of Waterloo, Waterloo, Ontario, CANADA N2L 3G1, (519) 885-1211 x3416 UUCP: ...!watmath!watdcsu!andytoy NetNorth/BITNET: andytoy@watdcsu INTERNET: andytoy@dcsu.waterloo.edu CDN: andytoy@dcsu.waterloo.cdn
gerard@tscs.UUCP (Stephen M. Gerard) (05/23/87)
In article <969@bobkat.UUCP> pedz@bobkat.UUCP (Pedz Thing) writes: > >I would like people posting programs to the net to describe briefly >what they do at the top of the article. Not a complete detailed >description but at least something that lets me know what they are >suppose to do. For example there is a program just posted called >filter. There is absolutely no comments at all about what it does or >how to use it. This is really really really really really stupid. If >you want people to use your software, you should at least let them >know what it is. > >This espeically applies to the moderated groups. You get titles like >FROB and a comment at the start of the first article that says ``This >is FROB version 2.5''. Inadequate! I have better things to do then >to keep track of all of the programs in the world and all of their >names. Not to mention the problem of the same name being used in more >than one program. The name of the program does not describe it. I agree! It is hard to decide to use/archive something if you don't know what it is. Useful information such as: Package Name - Version Number - Author - Part N of X - Brief Description Program Name: This should be what the executable is called or the name of the function library, etc. When you are archiving something for future disection, it helps to have a name to use without reading through the whole thing to determine what to call it. Version Number: Is this newer than what I already have, or is it a repost of some prehistoric version. It would also be nice if each module listed it's version number or last change date too. It is somewhat hard to remember to update the version number of something once you get it working, I forget this myself. It would be nice if the version number is included in the executable as well. This makes life easier when you find out the version that blows up is several revs old. Author(s): Who wrote it, and who hacked it. Part N of X: How many parts do we have of this version? Brief Description: What it does. Just enough to give an idea of what it is. Perhaps some sort of standardized header could be adopted for all source, and binary files posted. This way a little utility program could be written to rename and catalog each useful goodie that comes in over the net. It should not be hard to use standardized headers as the trend seems to be going to moderated groups for source postings. -Steve