论文与邮件

提交给委员会讨论的技术贡献以 N 编号的“文档”形式撰写。文档应采用 HTML、PDF 或文本格式。每个文档应以 WG21 文档编号、ISO 格式日期（yyyy-mm-dd）、标题和作者信息开头。

根据“纸质时代”的 ISO 和 ANSI/INCITS 规则，文档被分组为“邮件”，之所以这样称呼，是因为在 20 世纪，它们是在每次面对面会议前后通过邮政邮件分发的物理文件，尽管如今它们只以 HTML/TXT/PDF 文档的 ZIP/TAR 文件形式进行电子分发。

会前邮件包含将在即将召开的会议上审议的文档。在每次面对面会议之前几周，会有一个针对会前邮件中按时提交的文档的截止日期。在会议上，优先考虑邮件中按时提交的文档，这意味着参与者有时间消化它们，特别是那些无法参加面对面会议的国家机构专家有机会与他们的代表进行磋商，并带着立场和指示将他们送到会议上。

会后邮件包含会议上批准的更新文档，以及其他迟交和会议期间的文档，无论是否被采纳。

流式邮件：isocpp.org “标准化”类别

委员会文档现在一经提交就会通过 isocpp.org 博客链接，无需等待官方的“邮件”批次文档。（请注意，形式上，这是常规邮件的补充，而不是替代。）

您可以关注标准化博客类别，或者所有帖子，以便在它们可用后近乎实时地查看所有以下内容：

• 文档的预发布草稿（经作者许可）。
• 为下一批邮件提交的最终文档。
• 以网络友好方式呈现的整个邮件；请参阅此处的示例。

目标是实现更低的延迟、会议之间更好的迭代以及更广泛的公众评论。公众可以在宣布文档的博客文章上发表评论，或者通过在std-discussion或std-proposals上发起讨论来发表评论。

会议讨论哪些文档？

问

“在会前邮件发布之后但在会议开始之前发布的文档会怎样？它们会像会前邮件文档一样在会议中讨论吗？”

答： 实际上，我们很通情达理：分组主席优先考虑按时提交的文档，但他们也可以讨论迟交的文档。有时迟交甚至会议期间的文档只是之前讨论过的文档的更新，我们总是希望获得最新的有用信息。

只是请尽量避免在最后一刻提出新的提案。这种“新”的迟交文档（与之前文档的更新相反）在最后一刻到达的问题是，参与者——包括 .16 公司成员和未亲自出席会议的 WG21 国家机构成员——需要有机会事先消化和讨论它们，形成知情立场并提供有用的反馈，以便出席会议的 .16 投票成员、NB 专家和代表团团长能够合理地代表他们的选民，并充分利用会议时间。当我们做好准备时，我们就能减少在试图取得进展而徒劳无功的宝贵面对面时间。

所以，如果你正在撰写一份 WG21 文档，请争取让你的文档成为会前邮件中的按时文档，以便每个人都有机会进行磋商并消化它。你的回报是你知道它将在会议上被审议。然而，我们也通常乐于在会议前夕收到文档——但是文档越晚、越大或越新颖，在会议上分配讨论时间的可能性就越小。