But I hope that that doesn't mean that we can't discuss it first. I explained
my feelings about bloat before, but have some comments with respect to other
messages which have come across since then. (To continue about bloat briefly,
though, consider the fact that a disclaimer like this will likely grow in size
over time as more problems crop up, and will surely never shrink...)
Anyway: most fundamentally, note that "Approved:" has *always* meant form
rather than content; its meaning is not particularly different in *.answers
than in almost all (if not all) other moderated newsgroups. A few moderated
newsgroups' moderation software programs append disclaimers of this sort to
every message, but most do not. *.answers is, seemingly, running into this
issue in a few of the myriad newsgroups it rubs shoulders with, and while
disclaimers there may be indicated, I think it's an issue of those particular
newsgroups (or particular faq authors) and not a general *.answers issue.
The word "approved" is used in this way in real life too, and I haven't
heard of troubles relating from its use in real life. Although some people
do say "approved for posting" rather than simply "approved" (permission to
post on organizational bulletin boards, or that union's allocated bulletin
board space in the company, etc). But I don't think that the shortening of
"approved for posting" to simply "approved" as a usenet news header ought to
cause any legitimate confusion. (I realize that we may well be talking about
the other kind of confusion in the cases triggering the current discussion.)
Certainly I don't see why the disclaimer need be in the "auxiliary
headers" (those faqware-oriented headers in the body of the message).
Since "Approved" isn't there, I'd think that someone who sees "Approved"
in the news headers would see an X-Disclaimer in those same news headers
(if they weren't too enraged to be able to see one wherever it appears).
I don't see that this disclaimer ought to be *more* visible than the
approved line, if the approved line is the source of the problem.
David Alex Lamb writes:
>Flamewars are infrequent, but time consuming and (for me, at least)
>emotionally draining.
I agree that we should spend some effort to try to deflect the flamewars
from you to the faq author. Nevertheless I wonder a few things about the
choice of this particular tactic:
Would the flamewars you're thinking of have successfully been deflected
just because of this X-Disclaimer header? Or do you imagine a flame to
which you can respond citing the disclaimer header and then *that* is
sufficient to deflect it? If the latter, suppose you could respond to
the flame by asking the faq author in question to insert that disclaimer
header only THEN, when the trouble started, and then they did it for the
next posting, and if needed perhaps you (with the author's permission I
guess, but assume in this case that you received it) edited the existing
file on rtfm.mit.edu to add the disclaimer; if this happened, would that
have successfully deflected the flame fest at that point?
This is assuming that these news.answers-moderator-directed flames are
infrequent; if news-answers@mit.edu gets cc'd on every faq author flame, it
would be a different matter, of course. But I don't think that Mr Lamb is
saying that they do.
--"Pahle, Morten Gleditsch" writes: >'It works, don't fix it' is a 'stick your head in the sand' attitude >which leads to reactive management; typical of bad management.
It depends on what your definition of "works" is, I suppose. Yes, this is sometimes part of a journey down the path to bad management, especially if "works" is used loosely and there are genuine problems with the situation. However, another path to bad management is bureaucratic procedures (signing more forms, adding more disclaimers) which are designed to cope with imagined future problems with an ardour out of proportion to the problems themselves. Or which are based on something having happened just once, and then the procedure gets entrenched, and you gradually accumulate many such bizarre procedures.
I think that some things *should* be reactive. A certain class of problems is not *worth* anticipating in advance, at least not anticipating to the extent that it affects your public actions. Otherwise I'd never post to usenet at all for fear of being flamed.
I agree that many things should be "proactive". I did include some disclaimers in my own faq, but they weren't anything about saying that I was indeed the author of the faq, because I think that that was obvious and I don't think that comp.security.unix/misc attracts the kinds of kooks against whom the currently-discussed disclaimers would be appropriate. It does, however, attract a certain category of befuddled people looking to latch on to people, software, and documentation, and I felt it important to disclaim some responsibility for inaccuracies and disclaim any availability for free consulting. These disclaimers I did feel it important to include, but they're obviously not relevant to most faqs out there.
The *.answers moderators may feel, upon receiving a draft faq, that this particular kind of form-not-content-approval disclaimer is appropriate because of that particular file, and they should ask for it. I don't think that they likely had that reaction to the initial draft of my faq file and don't see the point in their asking for it in my case. Furthermore, since the request from the *.answers team to add such a disclaimer could equally mean that the faq author is a kook OR is beseiged by kooks, I don't see why it's insulting if it occurs subsequent to the initial approval.
Despite all of the above, I should reiterate that I will not fight a policy which states that we should all add that x-disclaimer thing. I am attempting to contribute to the formulation of the policy and I think that the policy as initially proposed is unnecessary.
I think that I should also state that I don't think this has anything to do with "free speach". I think it's an information-system design issue, as well as a kook-management issue.
regards,
[
Usenet Hypertext FAQ Archive |
Search Mail Archive |
Authors |
Usenet
]
[
1993 |
1994 |
1995 |
1996 |
1997
]
© Copyright The Internet FAQ Consortium, 1997
All rights reserved