FreeBSD Mailing Lists 常見問答集

發文時，請務必遵守該 mailing list 的遊戲規則。

不要作人身攻擊。好的網路公民，應該要有更高的言行標準。

請不要試圖作 Spam 行為(廣告、轉貼多處等不請自來行為)。 所有 mailing lists 都會積極禁止這些違規者，一旦有的話，那麼後果請自行負責。

發文時，請保持一行約 75 個字元就自動斷行，因為並不是每個看的人都有很炫的圖形介面(GUI)看信軟體。

請注意：事實上，網路頻寬並不是無限的。 並非每個讀者的頻寬都很大，所以若想貼一些像是 config.log 之類的設定檔內容，或是大量的 stack trace 紀錄，那麼請把它放在自己網站上，然後貼出該網址 URL 就行了。 還有一件事，請記住，這些信件都會被舊信資料庫保存下來，所以這樣作會造成保存的資料庫會很快被塞到很大， 甚至可能塞爆 Server 的硬碟空間。

文章是要讓人看得懂，所以請注意版面編排的可讀性，還有.. 千　萬　不　要　大　聲　嚷　叫!!!!! 這點可不只 FreeBSD mailing lists 才需如此注意， 請勿低估文章『基本編排』的重要性、連鎖效應。 信中的表達方式通常就代表著別人眼中的你，若文章讓人看了很吃力(霧煞煞)、拼字錯誤百出、 充滿語意或邏輯錯誤、或是文內充滿一堆驚嘆號，這會讓人對你印象觀感極差。

在一些特定的 list 場合，請用適當的語言來溝通。許多非英語系的mailing lists 可以到 這邊 查看看。

對於許多母語不是英語的人，我們都能諒解他們的苦楚，並且試著儘量多多包涵。 英文非母語的人，我們會儘量不惡意批評拼字或文法錯誤之處。 FreeBSD 在這方面，一直有相當優秀的紀錄，請讓我們繼續保持這傳統吧。

寫信時，請用相容標準的 Mail User Agent (MUA)程式。 不良的(或設定錯誤的)寄信程式 這裡列有許多信件格式的錯誤示範。以下是一些已知的寄信程式的不良示範：

如同上述所見，Microsoft 出的一堆寄信程式通常都是不相容標準格式的。 請儘量改用 UNIX® 上的寄信程式。若必須在 Microsoft 環境下使用寄信程式的話， 請記得確認設定是否正確。請儘量不要用 MIME 格式： 因為有一堆人都在濫用 MIME 信件格式。

請確認：時間與時區設定是否正確。 這問題看起來有點蠢，因為你寄出的信還是會到達 mailing list 上， 但是呢，每位 mailing lists 上的訂戶每天都會看數百封的信， 他們通常會把信件以標題跟時間作為排序依據。 若你的信沒有在第一篇正解之前就先出現的話，他們就會假設可能是漏收你這封信， 然後就沒再去看你那封信了。

請提供程式出現的相關訊息，像是 dmesg(8) 或者 console messages 也就是通常會出現在 /var/log/messages 出現的。 請不要用手打，因為這不僅很苦，而且也可能打錯字或亂掉原有格式。請直接把相關的 log 檔丟出來， 或是用編輯器來剪裁、或是用滑鼠複製/貼上來完成。舉個例子，如果是要把像是 dmesg 的程式訊息倒入到某個檔案去的話，那麼作法如下：

% dmesg > /tmp/dmesg.out

這樣子會把訊息送到 /tmp/dmesg.out 檔內。

在用滑鼠剪貼時，請注意是否有犯一些細節的剪貼壞習慣。 尤其是像貼 Makefiles 之類檔案時，由於 tab 鍵所打出來的分格，是屬於特殊字元。因此，在 GNATS PR 資料庫 上很常看到這類很常見的惱人問題： Makefiles 內的 tab 經過剪貼後，變成『空白(white space)』 或是困擾的 =3B escape sequence，這些會讓 committers 們十分不爽。

請適當調整文章引言長度。回文時，引言部份請引『有談到的』部分為主，但請不要過與不及。 應該保留涉及討論範圍的原文，這樣子才能讓沒看過前面文章的人知道是在講什麼，而非一頭霧水。

還有一點也很重要，原文若是幅度相當長的話，記得註明 "yes, I see this too"。

善用技巧來確認原文與自己寫的部份： 通常會在原文的每行前面加上 “> ” 以作記號。 請記得保留 “> ” 符號後面的空白，並且在原文以及你所寫的段落之間加上空行， 以便閱讀。

請不要斷章取義、穿鑿附會：通常對原始文章『斷章取義』、『穿鑿附會』會讓大家很不爽，因為他們原意並非如此，卻被曲解。

回文時，不要寫在原文上面(top post)。 這個意思是：若要回文時，請寫在原文下方，不要寫在原文上面，以免讓人有時空錯置的錯亂混淆。

(感謝 Randy Bush 提供笑話)