Boost 讨论政策
电子邮件讨论是将 Boost 成员联系在一起形成社区的纽带。如果讨论富有启发性和有效性，社区就会蓬勃发展。如果讨论沦为互相辱骂和恶意攻击，社区就会逐渐衰落并最终消亡。
可接受的主题
- 查询以确定对可能提交的库的兴趣。
- 关于提议或现有库的技术讨论，包括错误报告和求助请求。
- 对提议库的正式审查。
- 关于用户使用 Boost 库的体验报告。
- Boost 管理或政策。
- 应用于 Boost 库的编译器特定解决方法。
其他与 Boost 开发相关的主题可能会被接受，具体由版主决定。如果不确定，请继续发帖。版主会通知您。
不可接受的主题
- 商业产品的广告。
- 请求帮助使非 Boost 代码与您的编译器一起编译。请尝试使用 comp.lang.c++.moderated 新闻组。
- 请求帮助解释 C++ 标准。请尝试使用 comp.std.c++ 新闻组。
- 工作机会。
- 请求家庭作业的解决方案。
有效的发帖
大多数 Boost 邮件列表都承载大量的流量，因此您的帖子通常需要与许多其他通信竞争关注。本节描述了如何确保您的帖子产生预期的影响。
精心撰写的帖子值得付出努力
不要忘记，您是一位独立的作者，但有许多读者，您希望他们对您所说的话保持兴趣。为读者节省一点时间和精力通常值得您在撰写邮件时花费额外的时间。此外，Boost 讨论会被保存以供后世参考，作为我们所做工作的理由和历史记录。帖子的未来实用性取决于其可读性。
在主题行中包含库名称
当您的帖子与特定的 Boost 库相关时，在主题行的开头使用方括号包含库名称非常有用，例如：
主题：[Regex] 为什么此模式不匹配？
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** 以及某些 Web 客户端在这方面尤其糟糕。如果您的客户端存在此问题，请花时间清理它在引用文本中产生的混乱。请记住，即使您没有编写原始文本，它也是**您的**帖子；您能否表达您的观点取决于其可读性。
Microsoft 客户端还在原始邮件文本的开头创建了一个异常冗长的标题，并将光标放在邮件的开头，这鼓励用户在所有引用文本之前编写回复，而不是将回复放在上下文中。幸运的是，Dominic Jain 编写了一个实用程序，可以自动修复所有这些问题：Outlook Quotefix 用于 Outlook 用户和 OE QuoteFix 用于 Outlook Express 用户。
总结和参考之前的邮件
只有在长时间的讨论之后，尤其是在主题偏离或讨论已取得成果时，才需要对之前的线程进行总结。邮件系统会执行必要的跟踪以使邮件阅读器能够显示邮件线程（每个像样的邮件阅读器都支持此功能）。
如果您需要参考线程中或不同线程中较早的单个邮件，则可以使用指向邮件存档的 URL。为了使这些 URL 保持简短，您可以使用tinyurl.com。引用您链接到的邮件的相关部分通常很有帮助（如果引用很小）。
保持讨论线程的完整性
**在开始新主题时，始终发送新邮件**，而不是开始回复其他邮件并替换主题和正文。许多邮件程序可以检测到您开始的线程，并将新邮件显示为原始线程的一部分，这可能不是您的本意。为了您自己和他人的利益，请遵循此准则。通常，扫描相关邮件的人会决定他们已经完成了某个主题，并隐藏或删除整个线程：您的邮件会被错过，您将无法获得您想要的回复。
同样，**在回复现有邮件时，请使用邮件程序的“回复”功能**，以便回复显示为同一讨论线程的一部分。
**如果您是摘要邮件的订阅者，请不要回复摘要邮件**。您的回复将无法正确地进行线程化，并且可能具有错误的主题行。相反，您可以通过GMane 网页界面回复。
保持帖子的尺寸合理
邮件列表软件会自动将邮件和附件的大小限制在合理的范围内，通常为 75K，版主会不时调整此限制。此限制是对那些依赖拨号互联网访问的人的礼貌，并且说实话，没有人想阅读一个由 75K 错误消息文本组成的帖子。
避免在电子邮件中使用公司和保密页脚
请记住，邮件列表是公开可见的，包括未订阅该列表的人。不发布任何机密信息的责任始终在发件人，您电子邮件中可能包含的任何保密声明均无效。发送带有保密页脚的电子邮件是发件人的单方面行为，接收方无法接受或拒绝页脚中指定的条款。因此，页脚没有约束力，但可能会让人觉得强加于接收方。这种负面反应会降低您的邮件得到回复的可能性。
此外，如果您的页脚包含公司信息，例如公司名称、徽标、营销口号、联系人以及您在公司中的职位，这可能会被视为广告，这是明确禁止的。如果您的邮件需要您公开您的公司关联，请将此信息包含在邮件正文中，而不是将其附加到公司页脚中的每篇帖子中。
如果页脚是强制性的公司政策，请避免使用公司电子邮件帐户向邮件列表发送帖子。请改用非公司电子邮件帐户。
禁止的行为
禁止的行为将不会被容忍。版主会禁止滥用者的帖子。
火焰战争
人身攻击、为争论而争论以及所有其他属于“火焰战争”类别的行为都是禁止的。讨论应侧重于技术论点，而不是参与者的性格特征或动机。
第三方攻击
禁止攻击第三方，例如软件供应商、硬件供应商或任何其他组织。Boost 的存在是为了团结并服务于整个 C++ 社区，而不是贬低他人的工作。
这是否意味着我们禁止偶尔对麻烦的编译器提出的抱怨或挖苦？不，但要注意不要过分。
偏离主题的帖子
强烈不鼓励偏离可接受主题的讨论。虽然偏离主题的帖子通常是出于善意，并且不像其他滥用行为那样具有腐蚀性，但累积起来，这种干扰会损害讨论的有效性。
文化
除了技术技能外，Boost 成员还重视协作、对他人帮助的认可以及一定程度的礼貌。Boost 会员来自世界各地，年龄和其他特征也各不相同。将讨论视为在广为阅读的论坛中的同事之间进行的，而不是在几个密友之间进行的。
始终记住，人们阅读您的贡献所花费的累积精力与（已经很大的）Boost 成员数量成正比。因此，请投入时间和精力使您的邮件尽可能易读。遵守英语语法规则，例如正确的首字母大写。避免使用大量的非正式语言、口语或缩写，因为它们可能无法被所有读者理解。在提交邮件之前请重新阅读。
有效讨论的指南
应用社会工程学来防止激烈的技术讨论演变成争吵，并积极鼓励 Boost 赖以生存的合作。
- 问题是有帮助的。如果有人建议了一些您认为行不通的东西，那么以“这会编译吗？”或“这不会编译失败吗，或者我是否遗漏了什么？”这样的问题进行回复要比“这很蠢——它不会编译”要好得多。说“这在我的机器上编译失败，并且似乎违反了标准的 n.n.n 节”是另一种坚定而不粗鲁的方式。
- 如果讨论大部分都是没有代码的概论，发布一些示例代码可以将人们的注意力集中在实际问题上。
- 如果讨论大部分都是关于特定代码的，尝试讨论一些隐藏的假设和概论，这些可能阻碍了讨论的结束。
- 暂停一下通常是有效的。只需说：“让我考虑一两天。让我们暂停一下，消化一下目前的讨论。”
避免出现帕金森自行车棚现象。帕金森描述了一个委员会，该委员会成立是为了监督早期核电站的设计。议程上有三项：何时喝茶、自行车棚放在哪里以及如何确保核安全。喝茶很快就被认为是琐碎的而被放弃了。核安全只讨论了一个小时——它非常复杂、可怕且技术性强，以至于即使在专家中，也鲜有人对这些问题感到满意。然后，人们花费了无数的时间来讨论建造自行车棚（现代的等价物是停车场），因为每个人都认为他们理解了这些问题，并且觉得可以舒适地讨论它们。
库名称
为了确保书籍和文章中的一致性，我们采用了关于引用 Boost 库的约定。库名称可以以紧凑的形式用点分隔，如“Boost.Name”，也可以以长形式表示，如“Boost Name 库”。例如
Boost.Python 的用途与Boost 图形库大不相同。
请注意，“库”这个词不是名称的一部分，因此不应将其首字母大写。
请注意避免在讨论中混淆已被接受到 Boost 中的库和尚未被接受的库。作为 Boost 库被接受表明代码和设计已经通过了我们的同行评审流程；未能区分这一点会贬低那些已经通过该流程的库作者的辛勤工作。以下是一些描述潜在 Boost 库的建议方法
- 提议的 Boost Name 库
- Boost.Name 候选库
- Name 库（在适用情况下可能是最佳选择）
请注意，此策略仅适用于讨论，不适用于文档、目录结构，甚至潜在 Boost 库代码中的标识符。
