This document is based on years of experience with the Subversion mailing lists, and specifically addresses the problems seen most frequently on those lists. It should not be taken as a complete guide to mailing list etiquette — you can find one of those on the Net pretty easily if you want one.
If you follow these conventions when posting to the users@subversion.tigris.org or dev@subversion.tigris.org mailing lists, your post is much more likely to be read and answered.
Post to users@subversion.tigris.org if you have a question about Subversion, or if you think you've found a bug (developers read the users list too, so they'll see your bug report). If you want to discuss Subversion development, or post a code contribution, then mail dev@subversion.tigris.org.
When in doubt, mail users@, not dev@.
Please don't use lines longer than 72 columns. Many people use 80-column terminals to read their email. By writing your text in 72 columns, you leave room for quoting characters to be added in future replies without forcing a rewrapping of the text. The 72-column limit only applies to the prose part of your message, of course. If you're posting a patch, see the section on patches.
Some mailers do a kind of automatic line-wrapping, whereby when you're writing your mail, the display shows line breaks that aren't actually there. When the mail reaches the list, it won't have the line breaks you thought it had. If your mail editor does this, look for a setting you can tweak to make it show true line breaks.
Capitalize the first letter of each sentence, and use paragraphs. If you're showing screen output or some other sort of example, offset it so it's clearly separate from the prose. If you don't do these things, your mail will be much less readable than it could be, and many people will not bother to read it at all.
Make sure to use your mailreader's "Follow-up" or "Reply-to-all" or "Group reply" feature when responding to a list post. Otherwise, your mail will only go to the author of the original post, not to the whole list. Unless there's a reason to reply privately, it's always better to respond to the list, so everyone can watch and learn. (Also, many people who frequently get private responses to their posts have indicated that they would prefer those responses to go to the list instead.)
Note that the Subversion mailing lists do not modify the Reply-to header to redirect responses to the list. They leave Reply-to set to whatever the original sender had, for the reasons listed in http://www.unicom.com/pw/reply-to-harmful.html, in particular the "Principle of Least Damage" and "Can't Find My Way Back Home" sections. From time to time, someone posts asking why we don't set the Reply-to header. Sometimes that person will mention http://www.metasystema.org/essays/reply-to-useful.mhtml, which gives arguments in favor of modifying the Reply-to field. The list administrators are aware of both documents, and see that both sides of the argument have merits, but in the end have chosen not to modify the Reply-to headers. Please don't resurrect the topic.
Don't start a new thread (subject) by replying to an existing post. Instead, start a fresh mail, even if that means you have to write out the list address by hand. If you reply to an existing post, your mailreader may include metadata that marks your post as a followup in that thread. Changing the Subject header is not enough to prevent this! Many mailreaders will still preserve enough metadata to put your post in the wrong thread. If this happens, not only will some people not see your post (because they're ignoring that thread), but people who are reading the thread will waste their time with your off-topic post. The safest way to avoid this is to never use "reply" to start a new topic.
(The root of the problem is really that some mail interfaces do not indicate that the message generated by the "Reply" function is different from a fresh message. If you use such a program, consider submitting an enhancement request or a patch to its developers to make it show a distinction.)
If you do need to change the Subject header while preserving the thread (perhaps because the thread has wandered into some other topic), do it by making a post under the new subject with the old subject in parenthesis, like this:
Blue asparagus
|
|_ Re: Blue asparagus
|
|_ Yellow elephants (was: Re: Blue asparagus) <-- ### switch ###
|
|_ Re: Yellow elephants
Please don't reflexively chide people for top-posting. "Top-posting" is the practice of putting the response text above the quoted text, instead of interleaved with it or below it. Usually, the quoted text provides essential context for understanding the response, and so top-posting is a hindrance. Sometimes, people top-post when it would have been better to inter-post or bottom-post, and others chide them for this. If you must chide, do it gently, and certainly don't bother to make an extra post just to point out a minor problem like this. There are even situations where top-posting is preferable — for example, when the response is short and general, and applies to the entirety of a long passage of quoted text. So top-posting is always a judgement call, and in any case it's not a major inconvenience even when done inappropriately.
If you came here looking for advice on how to quote, instead of advice on how to not flame people for their bad quoting habits, see http://www.netmeister.org/news/learn2quote.html (Deutsch: http://learn.to/quote).
If you're posting a patch, start the subject line with [PATCH]. This helps our patch manager spot patches right away. If the patch addresses a particular issue, include the issue number as well: "[PATCH] issue #1729: ...". Developers who are interested in that particular issue will know to read the mail.
If you can, send your patch as an attachment, using a mime-type of text/x-diff, text/x-patch, or text/plain. Most people's mailreaders can display those inline, and having it as an attachment allows them to extract the patch from the message conveniently. Never send patches in archived or compressed form (e.g., tar, gzip, zip, bzip2), because that prevents people from reviewing the patch directly in their mailreaders.
If you can't attach the patch with a reasonable mime-type, or if the patch is very short, then it's okay to include it directly in the body of your message. But watch out: some mail editors can munge inline patches by inserting unasked-for line breaks in the middle of long lines. If you think your mail software might do this, then the patch must be sent as as an attachment.
Please include a log message with your patch. See HACKING for guidelines on writing log messages.
Please use ASCII or ISO-8859 text if possible. Don't post HTML mails, RichText mails, or other formats that might be opaque to text-only mailreaders. Regarding language: we don't have an English-only policy, but you will probably get the best results by posting in English — it is the language shared by the greatest number of list participants.
Look in the FAQ, and maybe poke around in the mailing list archives, before asking a question. The Subversion FAQ is here: http://subversion.tigris.org/faq.html. The mailing lists archives are here: http://subversion.tigris.org/servlets/SearchList?listName=users (for users@), and http://subversion.tigris.org/servlets/SearchList?listName=dev (for dev@).
A mirror of the mailing list archives, with a somewhat different interface, is at http://svn.haxx.se/users (for users@), and http://svn.haxx.se/dev (for dev@).