[このドキュメントの単一ページ版も参照できます。]
以下の助言は、Subversionのメーリングリストでの長年の経験に基づいており、これらのリストで最も頻繁に見られる問題に対処しています。 これは、メーリングリストのエチケットに関する完全なガイドとして解釈されるべきではありません— もしあなたがそれを望むなら、ネット上で見つけることができます。
メーリングリストに投稿する際にこれらの規約に従うと、あなたの投稿は読まれ、回答される可能性がはるかに高くなります。
迷ったときは、dev@subversion.apache.orgではなく、users@subversion.apache.orgにメールしてください。users@リストには、Subversionのメンテナを含む多くの経験豊富な人々がいます。彼らはあなたの質問に答えられるかもしれませんし、もしあなたがバグを見つけたと考えるなら、それが本物のバグかどうかを判断できます。新しい機能を提案したい場合でも、users@に投稿する必要があります。多くの機能提案は以前に議論されたことがあるアイデアであり、通常、users@subversion.apache.orgメーリングリストの誰かがあなたの提案がそうであるかどうかを教えてくれます。
users@で回答を得られなかった場合の最後の手段として、dev@に投稿しないでください。2つのリストには異なる目的があります。users@はサポートフォーラムであり、dev@は開発に関する議論リストです。サポートに関する質問がusers@で回答されない場合、それは残念なことですが、その質問がdev@に適しているわけではありません。
もちろん、メールがSubversionのバグの可能性に関するもので、users@で反応がなかった場合は、dev@で質問しても構いません—バグは開発トピックです。そして、パッチは常にdev@に直接送信する必要があります。
時々、あるトピックについて本当に熱心になると、メールスレッドのすべてのメッセージに返信したくなることがあります。しかし、そうしないでください。私たちのメーリングリストはすでに高トラフィックであり、すべてのメッセージに追従すると、ノイズが増えるだけです。
代わりに、メールスレッド全体を読み、あなたが言いたいことを慎重に考え、返信するメッセージを1つ選び、それからあなたの考えを述べてください。トピックが分岐し始めた場合にのみ、スレッド内の2つの異なるメッセージに返信することが理にかなっている場合があります。
72列よりも長い行を使用しないでください。多くの人がメールを読むために80列の端末を使用しています。テキストを72列で記述することにより、将来の返信で引用文字が追加されても、テキストの再折り返しを強制することなく、余白を残すことができます。もちろん、72列の制限はメッセージの散文部分にのみ適用されます。パッチを投稿する場合は、パッチに関するセクションを参照してください。
一部のメーラーは、自動的な行折り返しを行います。メールを書いているときに、表示される行の改行は実際には存在しません。メールがリストに届くと、あなたが思っていた改行はありません。メールエディターがこれを行う場合は、真の改行を表示するように調整できる設定を探してください。
各文の最初の文字を大文字にし、段落を使用します。画面の出力やその他の種類の例を示す場合は、散文とは明らかに区別できるようにオフセットします。これらのことを行わない場合、メールの読みやすさがはるかに低下し、多くの人がそれを読むことを面倒に思うでしょう。
リスト投稿に返信するときは、メールリーダーの「フォローアップ」、「全員に返信」、「グループ返信」機能を使用してください。そうしないと、あなたのメールは元の投稿の作成者にのみ送信され、リスト全体には送信されません。非公開で返信する理由がない限り、リストに返信する方が常に優れています。そうすれば、誰もが見て学ぶことができます。(また、投稿に頻繁にプライベートな返信を受け取る多くの人が、それらの返信を代わりにリストに送ってほしいと表明しています。)
SubversionのメーリングリストはReply-toヘッダーをリストへの返信をリダイレクトするように変更しません。彼らはReply-tohttps://www.unicom.com/pw/reply-to-harmful.htmlに記載されている理由、特に「最小限の損害の原則」と「家に帰る道が見つからない」セクションのために、元の送信者が持っていたものに設定されたままにします。時々、なぜReply-toヘッダーを設定しないのかを尋ねる人がいます。その人は時々、https://marc.merlins.org/netrants/reply-to-useful.htmlに言及します。これはReply-toフィールドを変更することに賛成する議論をしています。リスト管理者は両方のドキュメントを認識しており、議論の両側にメリットがあることを理解していますが、最終的にはReply-toヘッダーを変更しないことを選択しました。このトピックを復活させないでください。
既存の投稿に返信して新しいスレッド(件名)を開始しないでください。代わりに、リストアドレスを手書きする必要がある場合でも、新しいメールを開始してください。既存の投稿に返信する場合、メールリーダーは、そのスレッドのフォローアップとして投稿をマークするメタデータを含めることがあります。件名ヘッダーを変更しても、これを防ぐのに十分ではありません!多くのメールリーダーは、投稿を間違ったスレッドに入れるのに十分なメタデータを保持します。これが発生した場合、一部の人は(そのスレッドを無視しているため)投稿を見ることができないだけでなく、スレッドを読んでいる人はオフピックの投稿で時間を無駄にするでしょう。これを回避する最も安全な方法は、「返信」を使用して新しいトピックを開始しないことです。
(問題の根本は、一部のメールインターフェイスが「返信」機能によって生成されたメッセージが新しいメッセージと異なることを示していないことです。このようなプログラムを使用する場合は、機能強化のリクエストまたはパッチを開発者に提出して、区別を示すようにすることを検討してください。)
スレッドを維持しながら件名ヘッダーを変更する必要がある場合(おそらくスレッドが他のトピックに迷い込んだため)、新しい件名で投稿し、括弧内に古い件名を入れることでこれを行います。以下のように
Blue asparagus | |_ Re: Blue asparagus | |_ Yellow elephants (was: Re: Blue asparagus) <-- ### switch ### | |_ Re: Yellow elephants
トップポスティングに対して反射的に人々を叱責しないでください。「トップポスティング」とは、引用されたテキストの上に、テキストと織り交ぜる、または下ではなく、応答テキストを配置することです。通常、引用されたテキストは応答を理解するための重要なコンテキストを提供するため、トップポスティングは妨げになります。場合によっては、インターポストまたはボトムポストする方が良かった場合にトップポストする人がいて、他の人がこれを叱責します。叱責する必要がある場合は、穏やかに行い、このような小さな問題を指摘するために追加の投稿をする必要はありません。トップポスティングが望ましい場合もあります。たとえば、応答が短く一般的なものであり、引用された長いテキスト全体に適用される場合です。そのため、トップポスティングは常に判断が必要であり、不適切に行われた場合でも、大きな不便はありません。
悪質な引用習慣に対して人々を非難する方法についての助言の代わりに、引用方法についての助言を探しに来た場合は、https://www.netmeister.org/news/learn2quote.html(ドイツ語:http://www.afaik.de/usenet/faq/zitieren/download/zitieren-alles.html)を参照してください。
パッチを送信する方法については、こちらを参照してください。コードを修正するためのパッチだけでなく、これらのWebページを修正するためのパッチも送信できます。WebページのレポジトリURLはhttps://svn.apache.org/repos/asf/subversion/site/です。
可能であれば、ASCIIまたはISO-8859テキストを使用してください。HTMLメール、リッチテキストメール、またはテキストのみのメールリーダーでは不透明になる可能性のあるその他の形式を投稿しないでください。言語に関して:英語のみのポリシーはありませんが、英語で投稿することで最高の効果が得られるでしょう。それがリスト参加者の間で最も多くの人が共有する言語です。