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