Email Etiquette

You have probably been referred to this page because you've sent an email to myself or a mailing list I run, probably containing a question, which was difficult to deal with.

I'm perfectly happy to answer your question and help you out, but in return I'd like you to make life easy for me by sending normal email which is nice and easy for me to deal with.

I'm sorry if that sounds rude or lazy, but I seem to spend most of my life in front of an email client, and although I'm happy to help I'd really prefer not to have it made more difficult than is necessary.

To this end, I've reproduced on this page a few items of "Netiquette" which describe normal behaviour among Internet users, but with which some newcomers sometimes have difficulty. It starts with general email-related advice, and moves on to things which are more specific to Linux kernel problems.

If you have accidentally transgressed one or more of these guidelines and been referred to this page, your mail may have been rejected from the mailing list or have ended up in the spam folder, or I may have replied simply with the URL to this page. In that case, please fix whatever was wrong and try again.

1. Use the archives
   Firstly, please look at the mailing list archives for an answer. If you've downloaded the code and it doesn't compile out of the box, it's a fairly safe bet that you're not the first. The solution will be in the mailing list archives. If you're doing _anything_ that you expect others have tried, and having trouble with it, try the archives before asking the same questions again.
2. Don't send private mail unless necessary
   Don't send mail to me privately if it's about something which doesn't need to remain private, and if there's any chance that someone else might learn from the answer. Obviously I don't answer publicly to private mail, so nobody gets to benefit from the answer but you. I don't mind answering questions, but if everyone just mails me the same questions privately and I can't just give one answer on the list which enlightens everyone, then it's a complete waste of my time.
   
3. Ensure your references are correct
   The email standard (RFC 2822) says that all replies should have References: and In-Reply-To: headers which contain the unique message identification of the message to which the reply is made. There are two ways in which this is generally abused:
   • Some broken mail programs will send a reply with no References: or In-Reply-To: header, causing threading information to be lost.
   • Sometimes people have been observed to select an existing message on the mailing list, reply to it but modify the subject in an attempt to start an entirely new thread. If their email client is behaving correctly, the References: and In-Reply-To: headers mean that their message is _not_ a new thread as they intended, but appears as a continuation of the original thread.
4. Quote selectively
   When replying to a message, do not quote any more of it than is completely necessary for understanding the context of your reply. Make sure you delete any parts which aren't important to your reply.
5. Quote clearly
   When quoting a previous message or messages, make sure it is clear which part was said by whom. The most common method of quoting is to add a single '>' character and a space at the left-hand-side of the quoted text, which makes it clear what is quoted and what is your own original text. Since most people follow this convention, it follows that '> > ' is a quotation from part of a message which itself quoted from a previous message. Ensure that attributions are correct for all such levels of quotation.
6. Place your reply below the quoted text
   If you do need to quote any of the original message in your reply, your own followup should go below the text which you quoted. Do not under any circumstances quote the entire original message and place your entire reply at the top. You will simply be ignored.
7. Do not send HTML encoded messages
   HTML messages are larger and slower to download, generally slower to render on-screen, and are displayed differently to normal messages, which makes them immediately harder to read. Send plain text only -- the only people who need to use HTML for email are those sending spam, which is why many people send HTML mail straight to the spam bin.
8. Make your mail readable by formatting it correctly
   Email should have no more than 80 columns per line of text. Many email clients, when presented with long lines, will assume that the sender intended there to be no line break there, and will display the email with a horizontal scrollbar required to see the right-hand side of the lines. When coupled with broken email clients which send each paragraph in a single line, this makes mail very difficult to read.
9. Include all relevant information
   If you want someone to help you, don't make them guess. Some of them may be remarkably good at guessing, but that doesn't mean you should make them do it. So if you're reporting a problem, include all the relevant information about what you did and what went wrong. As long as it remains readable, it's better to include slightly too much information than too little.
10. Decode all kernel 'oopses'
    As a specific example of the above, if you are reporting a kernel 'oops', make sure it's completely decoded so that it refers to particular functions and is usable, rather than just having a bunch of random numbers which are only relevant to your particular kernel build.
11. If you send patches, test them yourself
    Many people seem to send patches to a mailing list with broken mail programs which eat whitespace or introduce line breaks where they shouldn't be. If you aren't 100% sure that your mailer doesn't do such things, test it for yourself first -- send the patch to yourself, then save the mail you receive and try to apply the patch. Don't just send it to busy people and hope.