On Fri, Sep 03, 2004 at 12:01:11AM -0500, kfogel@tigris.org wrote:
> Author: kfogel
> Date: Fri Sep 3 00:01:08 2004
> New Revision: 10809
>
> Added:
> trunk/www/mailing-list-guidelines.html
> Modified:
> trunk/www/project_tools.html
> Log:
> * www/mailing-list-guidelines.html: New file. Thanks to Paul
> Puschmann <paul.puschmann@medcom-service.de> for suggesting
> this and providing some initial material.
Couple comments on this set of guidelines...
There should be a section specifying that we don't consider consider it
appropriate to use derogatory or inflamatory language.
> +<a name="line-length"></a>
> +<li>
> +<p>Try not to use lines longer than 72 columns. This only applies to
> +the prose part of your message, of course. If you're <a
> +href="#patches">including a patch</a> or other specially formatted
> +text, those lines should be left at their original lengths. Watch
> +out: 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. There's usually a setting you can tweak to make it
> +stop doing that.<p>
> +</li>
Probably should just mention to see the section on patches for line
length issues regarding them, rather than duplicating them.
It might be useful to explain "Why 72 columns?"
Many people are using 80 column terminals to read their email. Using 72
columns leaves room for quoting characters to be added for future
replies without needing to rewrap the text to avoid it looking
exceedingly ugly.
> +<h2>Sending patches:</h2>
> +<a name="patches"></a>
> +
> +<ul>
> +
> +<li>
> +<p>If you're posting a patch, start the subject line with
> +<tt>[PATCH]</tt>. This helps our patch manager spot patches right
> +away. If the patch addresses a particular issue, include the issue
> +number as well: "<tt>[PATCH] issue #1729: ...</tt>".
> +Developers who are interested in that particular issue will know to
> +read the mail.</p>
> +
> +<p>It is unfortunately common for some mailreaders to munge patch text
> +that is included inline in the message body, for example by inserting
> +line breaks in the middle of long lines. If you think your mailreader
> +might do this, then send the patch as an attachment instead of putting
> +it directly in the message body. But if your mailreader doesn't
> +munge message bodies, then put the patch inline, because it's a bit
> +easier for people to see that way.</p>
> +</li>
I don't think everyone universally agrees with this. I much prefer
attachments provided that they have reasonable mime types specified.
text/x-diff, text/x-patch and text/plain are shown to me inline by my
mail client. Using an attachment saves me the bother of having to save
the entire message and edit it to get a clean patch if I want to apply
it later.
So I would revise this to specify that you should attach your patches if
you can do so with one of the above MIME types, if not you can inline it
provided your mail client won't munge it. As a last resort a patch can
be attached with some other mime type. Also patches should never be
archived or compressed (e.g. tar, gzip, zip, bzip2).
In my experience nobody seems to mind attachments provided they have
these reasonable mime types and aren't archived or compressed.
--
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 10 07:05:35 2004