2.1. | What should I do before I post? |
| You have already taken the most important step by
reading this document. However, if you are new to FreeBSD,
you may first need to familiarize yourself with the
software, and all the social history around it, by
reading the numerous
books and articles
that are available. Items of particular interest
include the
FreeBSD Frequently Asked Questions (FAQ) document,
the
FreeBSD Handbook,
and the articles
How to get best results from the FreeBSD-questions mailing list,
Explaining BSD,
and
FreeBSD First Steps. It is always considered bad form to ask a question that is
already answered in the above documents. This is not because
the volunteers who work on this project are particularly mean
people, but after a certain number of times answering the same
questions over and over again, frustration begins to set in.
This is particularly true if there is an existing answer to the
question that is already available. Always keep in mind that
almost all of the work done on FreeBSD is done by volunteers,
and that we are only human. |
2.2. | What constitutes an inappropriate posting? |
| Postings must be in accordance with the charter
of the mailing list. Personal attacks are discouraged. As good
net-citizens, we should try to hold ourselves to high
standards of behavior. Spam is not allowed, ever. The mailing lists are
actively processed to ban offenders to this rule.
|
2.3. | What is considered proper etiquette when posting
to the mailing lists? |
| Please wrap lines at 75 characters, since not
everyone uses fancy GUI mail reading programs. Please respect the fact that bandwidth is not
infinite. Not everyone reads email through high-speed
connections, so if your posting involves something like
the content of config.log or an
extensive stack trace, please consider putting that
information up on a website somewhere and just provide
a URL to it. Remember, too, that these postings will
be archived indefinitely, so huge postings will simply
inflate the size of the archives long after their
purpose has expired. Format your message so that it is legible, and
PLEASE DO NOT SHOUT!!!!!. Do not underestimate the
effect that a poorly formatted mail message has, and not
just on the FreeBSD mailing lists. Your mail message is
all that people see of you, and if it is poorly formatted,
badly spelled, full of errors, and/or has lots of exclamation
points, it will give people a poor impression of you. Please use an appropriate human language for a
particular mailing list. Many non-English mailing
lists are
available. For the ones that are not, we do appreciate that many
people do not speak English as their first language,
and we try to make allowances for that. It is considered
particularly poor form to criticize non-native speakers
for spelling or grammatical errors. FreeBSD has an
excellent track record in this regard; please, help us
to uphold that tradition. Please use a standards-compliant Mail User Agent (MUA).
A lot of badly formatted messages come from
bad
mailers or badly configured mailers. The following mailers
are known to send out badly formatted messages without you
finding out about them: exmh Microsoft® Exchange Microsoft® Outlook®
Try not
to use MIME: a lot of people use mailers
which do not get on very well with
MIME. Make sure your time and time zone are set correctly.
This may seem a little silly, since your message still
gets there, but many of the people on these mailing lists
get several hundred messages a day. They frequently sort
the incoming messages by subject and by date, and if your
message does not come before the first answer, they may
assume that they missed it and not bother to look. A lot of the information you need to supply is the
output of programs, such as dmesg(8), or console
messages, which usually appear in
/var/log/messages . Do not try to copy
this information by typing it in again; not only it is a
real pain, but you are bound to make a mistake. To send log
file contents, either make a copy of the file and use an
editor to trim the information to what is relevant, or cut
and paste into your message. For the output of programs
like dmesg , redirect the output to a
file and include that. For example, % dmesg > /tmp/dmesg.out
This redirects the information to the file
/tmp/dmesg.out . When using cut-and-paste, please be aware that some
such operations badly mangle their messages. This is of
particular concern when posting contents of
Makefiles , where tab
is a significant character. This is a very common,
and very annoying, problem with submissions to the
Problem Reports database.
Makefiles with tabs changed to either
spaces, or the annoying =3B escape
sequence, create a great deal of aggravation for
committers.
|
2.4. | What are the special etiquette consideration when replying
to an existing posting on the mailing lists? |
| Please include relevant text from the original message.
Trim it to the minimum, but do not overdo it. It should
still be possible for somebody who did not read the original
message to understand what you are talking about. This is especially important for postings of the type
"yes, I see this too", where the initial posting was dozens
or hundreds of lines. Use some technique to identify which text came from
the original message, and which text you add. A common
convention is to prepend
“> ” to the original
message. Leaving white space after the
“> ” and leaving empty
lines between your text and the original text both make
the result more readable. Please ensure that the attributions of the text
you are quoting is correct. People can become offended
if you attribute words to them that they themselves did
not write. Please do not top post . By this, we
mean that if you are replying to a message, please put your
replies after the text that you copy in your reply. (Thanks to Randy Bush for the joke.)
|