Boost 討論區政策
電子郵件討論是將 Boost 成員凝聚成社群的紐帶。如果討論熱烈且有效，社群就會蓬勃發展。如果討論淪為人身攻擊和惡意，社群就會凋零消亡。
可接受的主題
- 查詢以確定對可能的函式庫提交感興趣的程度。
- 關於提議或現有函式庫的技術討論，包括錯誤報告和求助請求。
- 對提議函式庫的正式審查。
- Boost 函式庫的使用經驗報告。
- Boost 管理或政策。
- 應用於 Boost 函式庫的編譯器特定解決方案。
其他與 Boost 開發相關的主題，由版主決定是否可接受。如果不確定，請發文。版主會告知您。
不可接受的主題
- 商業產品廣告。
- 請求協助讓非 Boost 程式碼使用您的編譯器進行編譯。請改用 comp.lang.c++.moderated 新聞群組。
- 請求協助解讀 C++ 標準。請改用 comp.std.c++ 新聞群組。
- 工作機會。
- 請求作業解答。
有效發文
大多數 Boost 郵件列表的流量很大，因此您的貼文通常需要與許多其他通訊競爭關注。本節說明如何確保您的貼文產生預期的影響。
精心撰寫的貼文值得付出努力
別忘了，您是一位作者，但讀者眾多，您希望他們對您所說的內容保持興趣。為讀者節省一點時間和精力通常值得您在撰寫訊息時花費額外的時間。此外，Boost 討論會被保存下來，作為我們工作的基本原理和歷史記錄。貼文未來的效用取決於其可讀性。
在主旨列中加入函式庫名稱
當您的貼文與特定的 Boost 函式庫相關時，建議在主旨列開頭用方括號括住函式庫名稱，例如：
主旨：[Regex] 為什麼這個模式不匹配？
Boost 開發者列表是一個高流量的郵件列表，大多數維護者沒有時間閱讀每則訊息。在主旨列上加上標籤有助於確保正確的人看到您的貼文。
不要使用 Tab 字元
如果您使用 Tab 字元縮排程式碼，請在將程式碼插入貼文之前將它們轉換為空格。處理鏈中的某些東西通常會去除所有縮排，留下混亂的程式碼。
限制行長
如果您在貼文中加入程式碼，而您的郵件程式會自動換行，請保持程式碼的窄度，或將程式碼作為（如果可能的話，嵌入式）附件插入。這將有助於確保其他人可以閱讀您發布的內容。
勿過度引用、勿置頂回覆，並使用嵌入式回覆以提高引言可讀性
回覆時請**修剪無關的引言文字**，僅保留相關部分。這樣可以節省時間，並讓您的貼文更有價值，讀者無需費力找出您回覆的是先前訊息的哪一部分。
不要置頂回覆；嵌入式回覆才是 Boost 列表適用的發文風格。
常見且非常實用的嵌入式回覆方法是引用您實際回覆的簡短訊息片段，並將您的回覆直接放在每個引用下方，用空行分隔以提高可讀性。
Person-you're-replying-to wrote: > Some part of a paragraph that you wish to reply to goes > here; there may be several lines. Your response to that part of the message goes here. There may, of course, be several lines. > The second part of the paragraph that is relevant to your > reply goes here; again there may be several lines. Your response to the second part of the message goes here. ...
關於在貼文中有效使用引言的更多資訊，請參閱這份實用指南。
保持引言格式一致
某些電子郵件和新聞客戶端使用不佳的自動換行演算法，導致來自同一段引言的連續行前導「>」字元數量不同。 **Microsoft Outlook** 和 **Outlook Express** 以及某些網頁客戶端在這方面尤其糟糕。如果您的客戶端有這種問題，請務必花時間整理引言文字的混亂。請記住，即使您不是原始文字的作者，這也是*您*的貼文；您是否能清楚表達您的觀點取決於其可讀性。
Microsoft 客戶端還會在原始訊息文字的開頭建立一個異常冗長的標頭，並將游標留在訊息的開頭，這會鼓勵使用者在所有引言文字之前撰寫回覆，而不是將回覆置於上下文中。幸運的是，Dominic Jain 撰寫了一個可以自動解決所有這些問題的工具：適用於 Outlook 使用者的 Outlook Quotefix 以及適用於 Outlook Express 使用者的 OE QuoteFix。
摘要和參考先前的訊息
只有在長時間討論後，尤其是在主題漂移或討論達成結果時，才需要先前討論串的摘要。郵件系統會進行必要的追蹤，讓郵件閱讀器能夠顯示訊息討論串（而且每個像樣的郵件閱讀器都支援此功能）。
如果您需要參考討論串中較早的單一訊息或不同討論串中的訊息，您可以使用指向訊息存檔的網址。為了讓這些網址保持簡短，您可以使用 tinyurl.com。引用您連結的訊息的相關部分通常很有幫助（如果引用簡短的話）。
維護討論串的完整性
**開始新主題時，請務必發送新訊息**，而不是回覆其他訊息並取代其主旨和內文。許多郵件程式可以偵測您開始的討論串，並將新訊息顯示為原始討論串的一部分，這可能不是您想要的。為了您自己和他人，請遵循此準則。通常，瀏覽相關訊息的人會認為他們已經完成某個主題，並隱藏或刪除整個討論串：您的訊息將被遺漏，您也得不到想要的回覆。
同樣地，**回覆現有訊息時，請使用郵件程式的「回覆」功能**，以便回覆顯示為同一討論串的一部分。
如果您是摘要郵件的訂閱者，**請勿回覆摘要郵件**。您的回覆將無法正確串聯，並且可能會有錯誤的主旨。您可以透過 GMane 網頁介面回覆。
保持您的貼文大小在可控範圍內
郵件列表軟體會自動將訊息和附件大小限制在合理範圍內，通常為 75K，版主會不時調整此限制。此限制是為了方便那些依賴撥接網路連線的使用者，而且坦白說，沒有人想閱讀一篇包含 75K 錯誤訊息文字的貼文。
避免在您的電子郵件中加入公司及保密聲明頁尾
請記住，郵件列表是公開可見的，包括未訂閱此列表的人也可以查看。不發布任何機密資訊的責任始終在於發送者，而您電子郵件中可能包含的任何保密聲明均屬無效。發送包含保密聲明頁尾的電子郵件是發送者的單方面行為，接收者無法接受或拒絕頁尾中指定的條款。因此，頁尾不具約束力，但可能會給接收者帶來壓力。這種負面感受會降低您的訊息得到回覆的可能性。
此外，如果您的頁尾包含公司資訊，例如公司名稱、標誌、行銷標語、聯絡方式以及您在公司中的職位，這可能會被視為廣告，而這是明確禁止的。如果您的訊息需要公開您的公司關係，請將此資訊包含在訊息正文中，而不是將其附加到您在公司頁尾的每篇貼文中。
如果頁尾是強制性的公司政策，請避免使用公司電子郵件帳戶向郵件列表發送貼文。請改用非公司電子郵件帳戶。
禁止行為
禁止行為將不被容忍。版主將禁止濫用者的貼文。
口水戰
禁止人身攻擊、為爭論而爭論，以及所有其他屬於「口水戰」類別的行為。討論應著重於技術論點，而不是參與者的性格特徵或動機。
第三方攻擊
禁止攻擊第三方，例如軟體供應商、硬體供應商或任何其他組織。Boost 的存在是為了團結和服務整個 C++ 社群，而不是為了貶低他人的工作。
這是否意味著我們禁止偶爾抱怨或諷刺令人困擾的編譯器？不，但要注意不要過度。
離題貼文
強烈不鼓勵偏離可接受主題的討論。雖然離題貼文通常是出於好意，而且不像其他濫用行為那樣具有個別的破壞性，但累積起來的分心會損害討論的有效性。
文化
除了技術技能外，Boost 成員還重視協作、感謝他人的幫助以及一定的禮貌。Boost 成員的國際化程度很高，年齡和其他特徵也差異很大。將討論視為在廣泛閱讀的論壇中同事之間的交流，而不是幾個親密朋友之間的閒聊。
請永遠記得，閱讀您貢獻內容的人所花費的累積時間會與（已經很大的）Boost 成員數量成正比。因此，請投入時間和精力使您的訊息盡可能易於閱讀。遵守英文語法和文法規則，例如正確使用大小寫。避免過度使用非正式用語、口語或縮寫，因為並非所有讀者都能理解。提交訊息前請重新閱讀。
有效討論的準則
運用社交技巧來防止激烈的技術討論演變成互相叫囂，並積極鼓勵 Boost 所仰賴的合作精神。
- 提問很有幫助。如果有人提出您認為行不通的建議，那麼以「這樣能編譯嗎？」或「這樣不會編譯失敗嗎？還是我漏掉了什麼？」之類的問題回覆，比「這太蠢了，根本編譯不了」要委婉得多。說「這對我來說無法編譯，而且似乎違反了標準的 n.n.n 節」是另一種既堅定又不會咄咄逼人的表達方式。
- 如果大部分的討論都是沒有程式碼的泛泛之談，貼上一段範例程式碼可以幫助大家聚焦於實際問題。
- 如果大部分的討論都圍繞著特定的程式碼，試著談談可能阻礙討論結束的隱含假設和概括性問題。
- 暫停一下通常很有效。只要說：「讓我思考一兩天。讓我們暫停一下，消化目前的討論內容。」
避免 _**帕金森單車棚效應**_。帕金森描述了一個負責監督早期核電廠設計的委員會。議程上有三項：何時喝茶、單車棚要設在哪裡，以及如何確保核安全。喝茶的問題很快就被當作瑣事處理掉了。核安全只討論了一個小時——它太複雜、太可怕、太技術性，即使是專家也很少有人能掌握這些問題。然後，他們花了無數天討論單車棚的建造（現代的等同物是停車場），因為每個人都認為自己了解這些問題，並且可以輕鬆地討論它們。
函式庫名稱
為了確保在書籍和文章中呈現的一致性，我們採用了一種約定俗成的 Boost 函式庫名稱寫法。函式庫名稱可以用帶點的簡短形式「Boost.Name」書寫，也可以用完整的形式「Boost Name 函式庫」書寫。例如：
**Boost.Python** 的用途與 **Boost Graph 函式庫** 截然不同。
請注意，「函式庫」一詞並非名稱的一部分，因此不需大寫。
在討論已被 Boost 接受的函式庫和尚未被接受的函式庫時，請注意避免混淆。被 Boost 接受為函式庫表示程式碼和設計已通過我們的同行評審流程；未能區分這一點會貶低那些通過該流程的函式庫作者的辛勤工作。以下是一些描述潛在 Boost 函式庫的建議方式：
- 提議的 Boost Name 函式庫
- Boost.Name 候選函式庫
- Name 函式庫（適用時最佳選擇）
請注意，此策略僅適用於討論，不適用於潛在 Boost 函式庫的文件、目錄結構，甚至程式碼中的識別字。
