2 Mailing List 的參與禮儀

最重要的是你已經看了這篇文章，然而，若您對 FreeBSD 不熟的話， 可能需要先廣泛閱讀 相關書籍及文章 來先熟悉這套作業系統和一些典故，尤其是其中的 FreeBSD 常見問答集 (FAQ) 文件， FreeBSD 使用手冊(Handbook)， 以及相關文章： How to get best results from the FreeBSD-questions mailing list、 Explaining BSD、以及 FreeBSD First Steps。

此外，對上述文件內已有解答的部份又提出來問的話，會被認為是相當不禮貌的。 這並不是因為這群志工是相當吝於回答的，而是一再被相同的問題不斷疲勞轟炸之後，所產生的挫折感很重。 尤其是現成答案明明就在眼前，卻仍同樣問題滿天飛，這實在是...。 請注意：這些 FreeBSD 相關文件幾乎都是由一群無薪志工的好心成果，而他們也是人。

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

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

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

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

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

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

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

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

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

  • cc:Mail

  • (舊版的)Eudora®

  • exmh

  • Microsoft® Exchange

  • Microsoft Internet Mail

  • Microsoft Outlook®

  • (舊版的)Netscape®

  如同上述所見，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)。 這個意思是：若要回文時，請寫在原文下方，不要寫在原文上面，以免讓人有時空錯置的錯亂混淆。

  • 答： Because it reverses the logical flow of conversation.

  • 問： Why is top posting frowned upon?

  (感謝 Randy Bush 提供笑話)