NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/news/groups/24994

Text File | 1993-01-01 | 24.6 KB | 576 lines

Newsgroups: news.groups
Path: sparky!uunet!think.com!ames!data.nas.nasa.gov!amelia.nas.nasa.gov!eugene
From: [e-mail] (Eugene N. Miya)
Subject: [l/m 12/3/92] FAQ on FAQs            n.g.FAQ
Followup-To: poster
Sender: [e-mail] (News Administrator)
Organization: NAS Program, NASA Ames Research Center, Moffett Field, CA
Date: Fri, 1 Jan 93 12:55:10 GMT
Message-ID: <[e-mail]>
Reply-To: [e-mail] (Eugene N. Miya)
Lines: 563

This is a prototype.

FAQs are the first generation of community memory.
They began with the efforts of Mark Horton, Spaf, Chuq, myself and others.
They are called "Frequently Asked Questions" files, but I prefer
"Frequently Answered Questions" as you will note the new news.group
is called news.answers, not news.asked.

Not every person calls them FAQ.  "Periodic post" is another term, and some
posts (e.g., in news.announce.newusers) don't have special names or
designations.  You have to learn to wing it.

Design issues:

1) Keep them short.  200 lines or less is preferable.

2) They will come in three basic types:
    a) netiquette: how to use the net
        always refer to news.announce.newusers
        why? for procedure for new group creations, etc.
    b) answers to informational queries.
    c) Misc.

3) Provide support for version control and killfiles.

4) Break the FAQ up.  Chain them.  Link them.

5) FAQs don't stop flame wars.  They don't limit free speech.
They should not limit speech.

6) Posting charters appears useful but is ultimately silly.  Your call.
You can't limit speech in an unmoderated group.  No enforcement, so I consider
this wasted bandwidth (bigger wastes exist).  If you want low noise,
minimum flaming, to avoid mass cross-posts by broadcasting novices, make
the group MODERATED, just like editing a Journal.  See comments on
appropriateness below.

7) If you can provide anonymous FTP, do so, but remember that not every one
has this luxury.

8) You will have some interesting times maintaining them.
(my personal chuckle comes on certain wilderness intestinal dysfunctions).

9) Develop them by consensus, BUT retain editorial control subject to
things like flames and liability.

10) FAQs have other useful functions like pulsing connectivity information
like a light house.

11) Frequency.  Good question, few good answers.
The naive FAQ maintainer posts once a month.
Others post by hand.  Still others post weekly.
Monthly posts are frequently never seen (FNS), whereas weekly posts
will get criticism as being noise (typically by those who have not learned
the 'n key or about Killfiles.
The hand poster typically has not discovered crontab yet.
They must have presence to have an affect.  Issues involve maintenance and
effect.  A problem is that FAQs grow (as memory does).
If they are not posted, they are not frequent themselves.
The current method under test is the FAQ chain with sections posted once a day.
Others clump parts and post all at once, assuming that expiration is
minimized using news group fields (doesn't work, many systems need the disk
space).  Multiple FAQs with multiple maintainers exist.  Some FAQs are
posted biweekly or once a month and a shorter weekly outrigger or outlier gets
posted for those times the FAQ isn't posted.

12) An FAQ should have no or a minimal signature line, strictly for
purposes of bounced email.  Otherwise, cute things like ASCII graphics
don't have a real place (usually).

13) Organization or design:  Several styles are popular.
The most popular: QAQAQAQA ... down a file.  (e.g., news.announce.newusers).
The most work is: Q-summary, QAQAQA (many colorful variations).
I like the "Jeopardy" style: AAAAA... (look the questions are obvious, just
provide the answers (like references). [Optional: determine the question.])

1.1) Sizes: Several useful message sizes are worth knowing.  200 line is an
    empirically determined human suggestion.  UUCP has a default 100 KB
    size limit.  Many sites change this: one have one machine for instance
    with a 30 KB limit.  Other systems have other limits, and then there
    are people's file systems [approaching 99% fullness]...
    Other people keep them to 1000 lines or less
    (do you know how many vt100-equivalent screenfuls 1000 lines is?).
    It is suggested that GIF or ASCII graphics be avoided.  Especially
    large files might require retransmission, and if problem result
    message thrashing can occur.
    Bottom line, try to keep them small and manageable.

1.2) No every one has an editor which does automatic line-wrap.  Limit
    line lengths to 72-75 characters.  Test the FAQ.

11.1) Header Expires: field:  Some news systems offer a feature to keep
certain articles around longer than most news system articles.  This is
optional, a system manager decides this.  Even in the best instances, it does
not appear that this field helps searchability or utility.  The idea being
that these articles will pull away from other expired articles does not
hold.  You are welcome to use them, but article length is more important.

Open issues: is the FAQ just a static file?  Or is it something
which is dynamic?

Some files like netiquette files are probably fairly static.
FAQs make poor books.  They should clearly be referenced.  Referencing is
of the standard argument/flame techniques on the net.  FAQs aren't flame-proof.
Nor should they be.  This is what makes the use of FAQs an open issue.

Known testable reader habits:

The typical user merely reads sequentially through a post: one screen-full
at a time, doesn't jump around, doesn't search, until they get to the
end of a post and automatically page or skip to the next post.  If they need
to get to the bottom, say like the last question of an FAQ, they scroll
(page) down there.

They will learn to skip and page, but they will not learn to use
Killfiles or search (much less use regular expression search).
The above paragraph holds until they learn to skip the reminder of an article:
the so-called 'n' key for 'next' article or note.

Most people will lurk (read, but not post).

Most people will skip news.announce.newusers.

Most people invoke readers on topic specific groups rather than wade through
thousands of uninteresting newsgroups.

We need to face several facts.  CRTs are a poor way to read text.
They search easy (if you know how), but we ignore typos more and we scan more
than read.  Many people dump FAQs (and other posts to printers).
FAQs should offer references to things like hardcopy media (e.g., books)
rather than give unreadable dissertations.  It is difficult to follow a
logical argument on a computer in a strictly serial fashion.  Our reading
(mostly at work) will not allow it.

It takes work to maintain an FAQ.  It is advised that reader should NOT
archive copies.  FAQs change and FAQs should appear frequently enough that
new versions can appear to answer questions.  Readers always tend to want it
NOW.  Email to the maintainer or anonymous FTP are a far better way to get it
than daily posts of the FAQ (this will happen, mark my word, that's a joke).

Inevitability, you will have an FAQ, and some clueless newbie will post
an article which the FAQ answers but they haven't seen.  Don't worry.
Propagation is poorer than you think (maybe only 80% get through).
Short queries aren't a problem.  Every one can post to the clueless (by
email) and say, "See the FAQ" [the FAQ-version of RTFM].

If the goal is to stop flame wars, and you wish to ignore point 5,
the best thing to do is an FAQ SUMMARY of all arguments,
challenge people to add more rational points on each side.
Then every one can point and say, "Arguments?  See the FAQ.  Let's move
on to other things."  We lack network history/memory.  The FAQ is not
perfect, but some of this works.  Cash incentives are useful.
A new book by Johnson and Koop (ex-Surgeon General) is a good example of this.

Systems which use Killfiles typically only grab the first 24 characters
of a Subject: line.  Any additional use of Killfiles requires extensive
editing, and not all readers these days know how to text edit.

Indices and tables of contents are helpful, but not always useful.
Most readers do not know of their capability to skip large regions of text.
This is why shorter files are more important than indexed files.

Most of our users have no idea the diversity (or lack of) in news interfaces.
The FAQ must work on the least common denominator.

Guidelines for moderation: proposing, accounting, etc.

Sci and the sci-oriented comp groups should probably mostly be moderated.
Separate open-forum groups can be created (name.d, d for discussion).
Talk groups should almost never be moderated.  If free speech is an issue,
then you should make it a talk group.  Rec and other groups can consider
moderation.  As one more option, you can proposed two groups: the primary one
moderated, the secondary one for discussion.  You will notice quite a
few groups with *.d endings (others do not: e.g., rec.arts.movies.reviews
& rec.arts.movies).  A bogus free speech argument would ask to list good
moderated groups (comp.risks: selections published hardcopy in CACM,
comp.compilers: 85% of the posts published in book form, comp.research.japan:
NSF funding for two years, rec.humor.funny is also published in hardcopy,
etc.).   They are out there, and they are good.

A real problem is that few people comprehend the number of news groups.
We have people who don't know how to propose a news.group, but also
propose groups which already exist.  There appears to be no way around this.

Copyright.
Face it, FAQs should not be copyrighted.  Or they should be copyrighted with
the greatest of copy permissions possible.  It's a public document (right?),
and if you are going to post it, you have to assume it's going to get every
where you would not want it, so ignore it.  Murphy's law will hold.
Credit can be due to authors, but it's a community document.

Usenet Self-Moderation Project

O.B.I.T.
Outer Band Individuated Teletracer

Grover: It *watches*, saps the very spirit.  And the worse thing of
all is *I* watch it.  I can't *not* look.  It's like a drug -- a horrible drug
You can't resist it.  It's an addiction.
...
Lomax: The machines are everywhere!  Oh, you'll find them all; you're a
zealous people.  And you'll make a great show out of smashing a few
of them, but for every one you destroy, hundreds of others will be built,
and they'll demoralize you, break your spirit, create such rifts and
tensions in your society that no one will be able to repair them!
You're a savage, despairing planet.  And when we come to live here, you
friendless, demoralized flotsam will fall without even a single shot
being fired.  You're all of the same dark persuasion.  You demand, *insist*
on knowing every private thought and hunger in everyone -- your families,
your neighbors, *everyone* but *yourselves!*

===== tag line =====

From [e-mail]  Thu Oct  1 13:57:05 1992
Received: from hopscotch.ksr.com by amelia.nas.nasa.gov (5.61/1.34)
    id AA10148; Thu, 1 Oct 92 13:57:05 -0700
Received: from ksr.com (frankenstein.ksr.com) by hopscotch.ksr.com with SMTP
    id AA26471; Thu, 1 Oct 1992 16:55:13 -0400
Received: by ksr.com (4.0/SMI-3.2)
    id AA02862; Thu, 1 Oct 92 16:54:08 EDT
Date: Thu, 1 Oct 92 16:54:08 EDT
From: [e-mail] (Dave Hudson)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: FAQ on FAQs
In-Reply-To: <[e-mail]>
Organization: Kendall Square Research, Waltham MA
Cc: [e-mail]
Status: RO

>Systems which use Killfiles typically only grab the first 24 characters
>of a Subject: line.  Any additional use of Killfiles requires extensive
>editing, and not all readers these days know how to text edit.

The easiest way to get a subject into a killfile is to let the
newsreader do it, while the kill is taking effect.  If dates,
"Frequently Asked Questions", "part M of N", or other crap are at the
beginning of the subject line, this will not get into the killfile in
a way that is convenient for edits.  Since the date is redundant, and
since if changes are important then they can be called out in a
"changes" edition or by use of changebars, dates ought not even be in
a FAQ's subject line.

So, if you're going to have a FAQ on FAQs, please recommend an
explicit format for subject lines, e.g.:
    "{Newsgroup,Interest} {Topic,} {(Changes),(# of #),}"

                David Hudson

From [e-mail]  Sun Nov  1 20:31:38 1992
Received: from netcom2.netcom.com by amelia.nas.nasa.gov (5.61/1.34)
    id AA05001; Sun, 1 Nov 92 20:31:38 -0800
Received: by netcom2.netcom.com (5.65/SMI-4.1/Netcom)
    id AA28936; Sun, 1 Nov 92 20:28:48 -0800
Date: Sun, 1 Nov 92 20:28:48 -0800
From: [e-mail] (Peter Kaminski)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: [l/m 10/6/92] FAQ on FAQs n.g.FAQ
Newsgroups: news.groups
References: <[e-mail]>
Organization: The Information Deli - via Netcom / San Jose, California
Status: RO

Nice document.

Some things I didn't see mentioned:

  The "Supersedes:" header, so that new posts can delete old ones out
  of the spool, especially for posts with "Expires:" headers.

  The use of "Followup-To: poster".  Sometimes the maintainer will want
  questions or comments to go directly to him/her.

  The structure used for the misc.kids FAQ suite: a periodically posted
  index to email addresses of maintainers/distributors of the actual FAQs,
  which are not posted.

Pete

From [e-mail]  Mon Nov  2 14:40:30 1992
Received: from uu3.psi.com by amelia.nas.nasa.gov (5.61/1.34)
    id AA21812; Mon, 2 Nov 92 14:40:30 -0800
Received: by uu3.psi.com (5.65b/4.0.071791-PSI/PSINet)
    id AA06193; Mon, 2 Nov 92 17:40:26 -0500
Date: Mon, 2 Nov 92 17:39:46 -0500
From: [e-mail] (Marc G. Frank)
Received: by avernus.com (5.67/3.2.083191-Maryland Appreciation Society)
    id AA01724; Mon, 2 Nov 92 17:39:46 -0500
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: [l/m 10/6/92] FAQ on FAQs            n.g.FAQ
Newsgroups: news.groups
In-Reply-To: <[e-mail]>
Organization: Maryland Appreciation Society
Cc:
Status: R

In article <[e-mail]> you write:
>This is a prototype.
>FAQs are the first generation of community memory.
>13) Organization or design:  Several styles are popular.
>The most popular: QAQAQAQA ... down a file.  (e.g., news.announce.newusers).
>The most work is: Q-summary, QAQAQA (many colorful variations).
>I like the "Jeopardy" style: AAAAA... (look the questions are obvious, just
>provide the answers (like references). [Optional: determine the question.])

I think you ought to recommend that FAQs be posted in digest format,
since most mail- and newsreaders have commands for skipping to the next
section of a digest.  IMHO, this increases the usefulness of any FAQ.

--
Marc G. Frank                                        Vote for Kibo:
[e-mail]                    The only candidate who knows
                                                 how to cross-post.

From ulogic!ulogic![e-mail]  Mon Nov  2 16:11:38 1992
Received: from netcomsv.netcom.com by amelia.nas.nasa.gov (5.61/1.34)
    id AA24601; Mon, 2 Nov 92 16:11:38 -0800
Received: from ulogic.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1)
    id AA21016; Mon, 2 Nov 92 17:08:45 PPE
To: [e-mail]
Subject: Re: [l/m 10/6/92] FAQ on FAQs            n.g.FAQ
Newsgroups: news.groups
In-Reply-To: <[e-mail]>
Organization: negligable
Cc:
Date: Mon, 2 Nov 92 15:58:30 PST
From: [e-mail]
Sender: [e-mail]
Message-Id:  <[e-mail]>
Status: R

In article <[e-mail]> you write:
>This is a prototype.

Then I presume you want comments....


First, perhaps section headers (Introduction, Guidelines, etc...) would
be useful?

>2) They will come in three basic types:
>    a) netiquette: how to use the net

This is a particular FAQ or two, not really a "genre" of FAQ...

>        always refer to news.announce.newusers
>        why? for procedure for new group creations, etc.
>    b) answers to informational queries.
>    c) Misc.

I'd just say that FAQs contain answers to questions (asked
or unasked :) about various topics, ranging from how to use the net,
to is homeopathy a valid form of treatment.

>4) Break the FAQ up.  Chain them.  Link them.

But maintain common Subject: lines if you do!

>13) Organization or design:  Several styles are popular.
>The most popular: QAQAQAQA ... down a file.  (e.g., news.announce.newusers).
>The most work is: Q-summary, QAQAQA (many colorful variations).
>I like the "Jeopardy" style: AAAAA... (look the questions are obvious, just
>provide the answers (like references). [Optional: determine the question.])
>
>1.1) Sizes: Several useful message sizes are worth knowing.  200 line is an

1.1 under 13?????  Shouldn't this be 13.1?

>    (do you know how many vt100-equivalent screenfuls 1000 lines is?).
>    It is suggested that ASCII or GIF graphics be avoided.  Especially

Avoid ASCII?  What *should* we use?

(upon closer reading it is ASCII graphics to be avoided, perhaps the
phrasing "GIF or ASCII graphics" would make this a bit clearer...)

>1.2) No every one has an editor which does automatic line wrap.  Limit
>    line lengths to 72-75 characters.  Test the FAQ.
>
>11.1) Header Expires: field:  Some news systems offer a feature to keep

13)
    1.1)
    1.2)
    11.1) ????????????

Definite renumbering called for here!!!

>Indices and table of contents are helpful, but not always useful.
>Because the ability to skip large regions of text is unknown by most readers.
>This is why shorter files are more important than indexed files.

Just because some people DON'T skip, doesn't mean we should
deprive the ones that can of the information that would be
useful for them.

At least recommend that indexes be placed in the larger files?

    -Richard Hartman
    [e-mail]

From ncoast![e-mail]  Tue Nov  3 04:06:38 1992
Received: from usenet.INS.CWRU.Edu by amelia.nas.nasa.gov (5.61/1.34)
    id AA03942; Tue, 3 Nov 92 04:06:38 -0800
Received: from ncoast.UUCP by usenet.INS.CWRU.Edu with UUCP (5.65b+ida+/CWRU-1.5.2-UUCPGW)
    id AA04217; Tue, 3 Nov 92 07:06:34 -0500 (from ncoast!brown for [e-mail])
Received: by ncoast.org (Smail3.1.28.1 #1)
    id m0mmEnR-00001RC; Mon, 2 Nov 92 22:19 EST
Message-Id: <[e-mail]>
Date: Mon, 2 Nov 92 22:19 EST
From: [e-mail] (Stan Brown)
To: [e-mail]
Subject: Re: [l/m 10/6/92] FAQ on FAQs            n.g.FAQ
Newsgroups: news.groups
In-Reply-To: <[e-mail]>
Organization: Oak Road Systems, Cleveland Ohio USA
Cc:
Status: R

A suggestion if I may.  I've noticed a couple of your FAQs crossposted
to news.answers, and have been much puzzled by their Subject: lines.
When I saw your post in news.groups I felt I had to write.  I hope what
I have to say will be helpful.

You might want to consider putting the most inportant information
first, and the last-modified date last.  My newsreader -- and I imagine
I'm far from alone in this --  cuts off the end of subject lines.  For
FAQs crossposted to news.answers, that means that I don't get to see the
names of the newsgroups unless I actually select and read the articles.

My suggestion, for what it's worth, is to put the newsgroup name or
other subject at the start of the subject line, and also to avoid
cryptic abbreviations.  I have no reason to think myself more stupid
than other people, but I scratched my head over "l/m" and I have no idea
what "n.g." is supposed to mean.  Obviously you take some time over
preparing your articles, and I assume it's because you want to
communicate.  But the things I mention get in the way.

Regards,

Stan Brown, Oak Road Systems,
Cleveland, Ohio, USA                              [e-mail]

From ncoast![e-mail]  Wed Nov  4 15:13:43 1992
Received: from data.nas.nasa.gov by wilbur.nas.nasa.gov (5.61/1.34)
    id AA17153; Wed, 4 Nov 92 15:13:43 -0800
Received: from usenet.INS.CWRU.Edu by data.nas.nasa.gov (5.61/1.34)
    id AA05809; Wed, 4 Nov 92 15:13:35 -0800
Received: from ncoast.UUCP by usenet.INS.CWRU.Edu with UUCP (5.65b+ida+/CWRU-1.5.2-UUCPGW)
    id AA24436; Wed, 4 Nov 92 18:13:32 -0500 (from ncoast!brown for [e-mail])
Received: by ncoast.org (Smail3.1.28.1 #1)
    id m0mmtk4-0000bEC; Wed, 4 Nov 92 18:02 EST
Message-Id: <[e-mail]>
From: [e-mail] (Stan Brown)
Subject: Re: [l/m 10/6/92] FAQ on FAQs            n.g.FAQ
To: [e-mail] (Eugene N. Miya)
Date: Wed, 4 Nov 1992 18:02:27 -0500 (EST)
In-Reply-To: <[e-mail]> from "Eugene N. Miya" at Nov 3, 92 10:49:08 am
X-Mailer: ELM [version 2.4 PL3]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Length: 1380
Status: R

My suggestions are just that, and are limited by my own situation.
The abbreviations and such that you are using have the flavor of being
intended for an in-group: are you really sure they are appropriate for
news.answers which is _intended_ for people who do not subscribe to the
groups where the postings originate?  I would think that crossposting to
news.answers is good, but the subject lines should be intelligible to
readers of news.answers.  Such is my _opinion_, FWIW.

Regards,

Stan Brown, Oak Road Systems,
Cleveland, Ohio, USA                              [e-mail]

> I take your suggestion into account and will consider how best to
> answer.
>
> For now let me explain that the syntax of the example subject line is
> made that way for Killfiles.  Most Killfile systems use the
> first 24 characters of the Subject for an initial cut on what to Kill.
> It is the use of Killfiles with FAQs we are seeking.  It's a crude
> mechanism, but it's the one which exists.  We are in the midst of testing
> various FAQ designs with the array of news systems out there
> trying to come up with reasonable designs and VALIDATING them.
> So if you can think of better ways (untried please suggest those, too).
> L/m: last modified: human readable/rememberable version control
> n.g.: news.groups.  Goes with FAQ and does not take up space.  Test
> variables.
>
>

From [e-mail]  Tue Dec  1 05:48:16 1992
Received: from uwasa.fi by amelia.nas.nasa.gov (5.61/1.34)
    id AA28518; Tue, 1 Dec 92 05:48:16 -0800
Received: by uwasa.fi (4.1/101091(hh))
    id AA08295; Tue, 1 Dec 92 15:48:12 +0200
Date: Tue, 1 Dec 92 15:48:12 +0200
From: [e-mail] (Timo Salmi)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: [l/m 10/6/92] FAQ on FAQs            n.g.FAQ
Newsgroups: news.groups
In-Reply-To: <[e-mail]>
Organization: University of Vaasa, Finland
Cc:
Status: R

In article <[e-mail]> you write:
>FAQs are the first generation of community memory.

Hello Eugene,

Very good.  As an active FAQ writer myself I have some comments.
(Mine are the comp.binaries.ibm.pc.wanted, comp.binaries.ibm.pc.archives
and a more general FAQ garbo.uwasa.fi:/pc/ts/tsfaq30.zip covering
some of the same issues as you do here, and covering Turbo Pascal).

My own number one rule of FAQs.  There is nothing wrong with asking
a FAQ.  (How else could a FAQ become a FAQ :-).

>6) Posting charters appears useful but is ultimately silly.  Your call.
>You can't limit speech in an unmoderated group.  No enforcement, so I consider
>this wasted bandwidth (bigger wastes exist).  If you want low noise,
>minimum flaming, to avoid mass cross-posts by broadcasting novices, make
>the group MODERATED, just like editing a Journal.  See comments on
>appropriateness below.

   Here I don't fully agree.  If the noise level is a tolerable
UseNet average, then ok, but there are cases where the newsgroups
have virtually collapsed because of no peer pressure.  In some
groups misposting rates do skyrocket.  (I have recent examples in
mind, but details are beside the point).  Besides one does not just
make a group moderated.  As we know it is a lengthy process.
   I would suggest taking a still more balanced wording of this
item.  Note that mostly I agree with you, but the way it is now I
feel you are making a bit too much of a blanket statement.
   (As to anarchy, I have sometimes have the feeling that especially
users from the US sometimes think that free speach is tantamout to
an unlimited ticket to anarchy).

>7) If you can provide anonymous FTP, do so, but remember that not every one
>has this luxury.

Consider mentioning mail servers.

>10) FAQs have other useful functions like pulsing connectivity information
>like a light house.

You lose me here by the show of the high-flying verbal virtuosity :-).

   All the best, Timo

..................................................................
Prof. Timo Salmi
Moderating at garbo.uwasa.fi anonymous FTP archives 128.214.87.1
Faculty of Accounting & Industrial Management; University of Vaasa
Internet: [e-mail] Bitnet: salmi@finfun   ; SF-65101, Finland