Ben Reser <ben@reser.org> writes:
> 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.
I'm trying to keep it to stuff we actually see happening regularly.
We don't have much of a problem with derogatory or inflammatory
language on this list. In the rare cases where we do, my impression
is that it comes from people who are unlikely to change their behavior
just because we point them to a set of guidelines. (We usually react
quickly to quash it on the list anyway.)
> > +<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.
Good suggestions both -- will tweak accordingly.
> > +<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.
Okay. I kind of prefer them inline, but I think I'm in a minority
there; I'll change it to your suggestion above.
Thanks for the feedback!
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 10 20:46:11 2004