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 用户的 Outlook Quotefix 和针对 Outlook Express 用户的 OE QuoteFix。
总结和引用较早的消息
仅在长时间讨论之后，才需要总结前面主题，尤其是在主题漂移或在讨论中取得结果时。邮件系统将进行所需的跟踪，以使邮件阅读器能够显示消息主题（并且每个体面的邮件阅读器都支持它）。
如果您必须引用主题或不同主题中较早的单个消息，则可以使用指向消息存档的 URL。为了帮助保持这些 URL 简短，您可以使用 tinyurl.com。引用您链接的消息的相关部分通常很有帮助（如果引用很小）。
维护讨论主题的完整性
在开始一个新主题时，始终发送一条新消息，而不是开始回复其他消息并替换主题和正文。许多邮件程序可以检测到您开始的主题，并将新消息显示为原始主题的一部分，这可能不是您想要的。为了您自己和他人着想，请遵循此准则。通常，扫描相关消息的人会决定他们已经完成了某个主题，并隐藏或删除整个主题：您的消息将被错过，并且您将不会得到您想要的回复。
同样，在回复现有消息时，请使用邮件程序的“回复”功能，以便回复显示为同一讨论主题的一部分。
如果您是摘要订阅用户，请不要回复摘要。您的回复将不会被正确地设置为主题，并且可能具有错误的主题行。相反，您可以通过GMane Web 界面进行回复。
保持帖子大小可管理
邮件列表软件会自动将消息和附件大小限制为合理的数量，通常为 75K，版主会不时调整此数量。此限制是为了方便那些依赖拨号 Internet 访问的人，而且，没有人想阅读包含 75K 错误消息文本的帖子。
避免电子邮件中的公司和机密性页脚
请记住，邮件列表是公开可见的，包括未订阅该列表的人。不发布任何机密信息的责任始终在发件人身上，并且您在电子邮件中可能包含的任何机密性声明均无效。发送带有机密性页脚的电子邮件是发件人的单向操作，收件人无法接受或拒绝页脚中指定的条款。因此，页脚不具有约束力，但可能会给接收者带来强加感。这种负面接待会降低您的消息被回复的可能性。
此外，如果您的页脚包含公司信息，例如公司名称、徽标、营销口号、联系人和您在公司中的职位，则这可能被视为广告，这是明确禁止的。如果您的消息需要您暴露您的公司隶属关系，请将此信息包含在您的消息正文中，而不是将其附加到您在公司页脚中的每个帖子中。
如果页脚是强制性的公司政策，请避免使用公司电子邮件帐户向邮件列表发送帖子。请改用非公司电子邮件帐户。
禁止的行为
禁止的行为将不被容忍。版主将禁止滥用者的帖子。
口水战
人身侮辱、为争论而争论以及所有其他属于“口水战”类别的行为均被禁止。讨论应侧重于技术论据，而不是参与者的人格特质或动机。
第三方攻击
禁止攻击第三方，例如软件供应商、硬件供应商或任何其他组织。Boost 的存在是为了团结和服务整个 C++ 社区，而不是贬低他人的工作。
这是否意味着我们禁止偶尔抱怨或嘲笑麻烦的编译器？不，但要警惕过度。
离题帖子
强烈建议不要进行偏离可接受主题的讨论。虽然离题帖子通常是善意的，并且不像其他滥用行为那样具有腐蚀性，但累积起来，这种干扰会损害讨论的有效性。
文化
除了技术技能外，Boost 成员还重视协作、感谢他人的帮助以及一定程度的礼貌。Boost 会员资格非常国际化，年龄和其他特征差异很大。将讨论视为在广泛阅读的论坛中同事之间进行，而不是在少数亲密朋友之间进行。
请始终记住，阅读您贡献内容的人所花费的累积精力会随着 Boost 成员数量（已经很大）而增加。因此，请投入时间和精力，使您的消息尽可能易于阅读。请遵守英语语法规则，例如正确的大小写。避免大量非正式用语、口语或缩写，因为并非所有读者都能理解。在提交消息之前请重新阅读。
有效讨论的指导原则
应用社会工程学，防止激烈的技术讨论演变成争吵，并积极鼓励 Boost 赖以存在的合作。
- 提问有所帮助。如果有人提出了您认为行不通的建议，那么回复一个类似“这会编译吗？”或“这样不会编译失败吗？还是我遗漏了什么？”的问题，要比“这太蠢了 - 它不会编译”好得多。说“这在我这里编译失败，并且似乎违反了标准第 n.n.n 节”也是一种既坚定又不失礼貌的方式。
- 如果大部分讨论都是关于没有代码的泛泛而谈，那么发布一些示例代码可以让人们关注实际问题。
- 如果大部分讨论都是关于特定代码，请尝试谈论一些可能阻碍讨论结束的隐藏假设和普遍性问题。
- 暂停通常是有效的。只需说：“让我考虑一两天。让我们暂停一下，消化一下目前的讨论。”
避免帕金森自行车棚。帕金森描述了一个为监督早期核电站设计而成立的委员会。有三个议程项目——何时喝茶、自行车棚放在哪里以及如何确保核安全。喝茶因为无关紧要而被迅速处理。核安全仅讨论了一个小时——它太复杂、可怕和技术性强，以至于即使在专家中，也很少有人对这些问题感到舒服。然后，人们花了无数天来讨论自行车棚的建设（停车场将是现代的等效物），因为每个人都认为他们理解这些问题并且可以轻松地讨论它们。
库的名称
为了确保在书籍和文章中呈现一致，我们采用了引用 Boost 库的约定。库名称可以以紧凑的形式用点号表示，如“Boost.Name”，也可以以长形式表示，如“the Boost Name library”。例如
Boost.Python 的用途与 the Boost Graph library 非常不同。
请注意，“library”这个词不是名称的一部分，因此不应大写。
请注意避免在讨论中混淆已接受加入 Boost 的库和尚未加入的库。被接受为 Boost 库表明该代码和设计已经通过了我们的同行评审流程；未能区分这一点会贬低那些经过该流程的库作者的辛勤工作。以下是一些描述潜在 Boost 库的建议方式
- the proposed Boost Name library (提议的 Boost Name 库)
- the Boost.Name candidate (Boost.Name 候选库)
- the Name library (probably the best choice where applicable)（Name 库（在适用情况下可能是最佳选择））
请注意，此策略仅适用于讨论，不适用于潜在 Boost 库的文档、目录结构甚至代码中的标识符。
