主页 » 标准化 » 常设文件 » SD-4：WG21 实践和程序

SD-4：WG21 实践和程序

Doc No: ISO/IEC JTC1/SC22/WG21/SD-4
Date: 2024-12-30
Project: JTC1.22.32 
Reply To: Herb Sutter
          Convener, SC22/WG21
          Email: [email protected]

WG21 实践和程序：“我们如何工作”备忘单

目录

目的和受众

本文件包含适用于所有 WG21 活跃参与者（即经认可的国家机构专家，尤其是那些参加我们面对面会议的专家）的重要信息。虽然本文件对新参与者快速上手也很有用，但其中涵盖的材料涉及我们会议、电子邮件列表、正式投票和其他参与中经常出现的程序和情况，所有参与 WG21 的人都应熟悉这些信息。

本文件总结了 WG21 目前的一些实践和程序，此外还有可在 ISO 指令与政策页面上获取的 ISO/IEC 指令与 JTC 1 补充文件的要求。

本文件将用“ISO”或类似字样标明明确的规则，否则记录我们 WG21 特定的实践，以实施 ISO 指南和组织我们的会议。

注意：本文件不重复以下已涵盖的基本材料：

行为准则

我们遵循 ISO 道德和行为准则（2023 年 3 月）和IEC 行为准则——统称为“准则”。(另见：ISO 道德和行为准则 - 实施（2023 年 3 月）)

若要报告有关潜在行为准则违规行为的疑虑，请遵循 ISO 文件“处理不当行为和违反行为准则的指南和程序”中的步骤。

每次会议开始时，我们都会展示以下 ISO/IEC JTC 1 幻灯片：

ISO 和 IEC 关于道德和尊重对 JTC 1 委员会的关注的重要信息

升级和解决争议

  • 及时识别和升级争议，以便快速解决
  • 遵守商定的争议解决程序

道德行为

  • 真诚、审慎和勤勉地行事
  • 避免串通或反竞争行为
  • 促进公平和道德行为的文化

在会议中尊重他人

  • 专业
  • 尊重他人及其意见
  • 接受团体决定
  • 确保所有观点都得到倾听和理解
  • 容忍不同的文化习俗
  • 避免使用隐喻、讽刺，并注意笑话和幽默可能无法翻译

在社交媒体上尊重他人

  • 尊重而非辱骂
  • 不要说出你可能会后悔或不想让你的朋友、家人或同事看到的话

共识

ISO/IEC 指南 2:2004 中引用 ISO/IEC 指令，共识定义如下：

共识：普遍同意，其特点是相关利益的任何重要部分对实质性问题没有持续的反对意见，并且通过一个旨在考虑所有相关方的观点并调和任何冲突论点的过程。

注：共识不一定意味着全体一致。

重要的是，请注意共识不是什么：

  • 共识不是多数人的暴政。多数人不能仅仅说“我们有足够的票数”就拒绝倾听少数人的担忧。ISO 行为准则要求多数人“确保所有人的观点都得到倾听和理解”。

  • 共识不是少数人的暴政。少数人，一旦他们有机会被倾听，不能仅仅说“我们仍然反对，所以你们不能继续”就拒绝接受多数人追求不同方向的共识。ISO 行为准则要求少数人“接受集体决定”。

  • 共识并不排除明智的升级（“抛出异常”）。在极少数情况下，如果少数人仍然认为正在犯严重的判断错误，可以根据本文件后面介绍的升级程序进行适当的升级；请注意，关键词是“罕见”（不经常）、“仍然”（以前提出过）和“严重”。ISO 行为准则鼓励“及时升级争议”并采用“商定的争议解决程序”。升级可能在两种情况下变得不适当：(a) 未“及时”提出严重异议，例如将其保留到全体会议或正式投票时间，而不是从过程开始时就尽早并持续提出；或 (b) 参与者或国家机构经常使用升级程序来表达对一个又一个主题的强烈分歧，这会削弱他们的可信度，并且不符合升级解决程序的宗旨（就像异常处理一样，升级处理适用于严重错误，而不是用于表达不太严重的情况或应该属于普通控制流的情况）。

提案和文档

如果提案没有文档，则它不存在。任何重要的提案都需要一份文档，包括每个作为设计添加或更改的提案。

注意：对于仅涉及改进标准措辞以实现既定设计的次要问题，无需文档。这些问题不影响设计本身，可以仅列在问题列表中。

高质量的提案文档。提案文档远不止是写下来的“想法”。一份好的提案文档应该：

  • 以示例为基础：展示目前编写代码存在问题并需要改进的激励性示例。展示所提议功能的使用示例，包括如果拥有新提议功能，这些激励性示例会是什么样子。

  • 以原则为基础：阐明所提议解决方案的设计原则。展示所提议解决方案如何与语言的其余原则和设计理念相符（注意：明确不包括语言的怪癖）。理想情况下，应引用C++ 的设计和演变 (D&E)中阐述的原则/理念。

  • 显示已考虑的设计替代方案：并附有具体的示例，说明为何未采用这些方案。作者应表明他们已相当彻底地考虑了问题，而不仅仅是采纳了第一个想到的想法。

这三点是区分“某人的酷想法”（可能有趣但程序上无用）和“真实提案”（可以认真评估和推进）的主要因素。

注：有关撰写提案的更多详细信息，另请参阅

按时提交的文档。所有要在会议上审议的文档都必须在会议前邮件截止日期前收到。每次会议的议程包括自上次会议以来邮件中包含的所有文档（从上次会议的会后邮件到本次会议的会前邮件，包括在内），以及可能由小组主席判断在上次会议中未充分处理的选定早期文档。要求文档按时收到，可确保国家机构专家有足够时间提前审议提案，并准备好参加富有成效的讨论。

迟交的文档。未在上次会议后按时提交文档的提案无法采取行动，在官方会议时间内将不予审议；鼓励作者提交修订版作为未来会议的按时提交文档。（注：按时提交文档的后续文档，例如迟交或会议中对按时提交文档的反驳/阐述/更新文档，当然可以审议；它们是审议按时提交文档的一部分。）

推论：如果一个主题没有至少一个按时提交的文档，那么整个主题就不在会议议程上。坚持已发布的议程，包括会议前邮件中发布的文档主题，对于确保所有利益相关者都有充分的机会出席，从而使我们能够有序地进行工作至关重要。根据 ISO 规则，如果 WG 会议对议程上未提及的主题（包括按时提交的文档主题）采取行动，国家机构可以在 SC 22 和 JTC 1 中正式升级对整个 WG 会议的异议，理由是国家机构没有收到充分通知，无法派遣任何（或正确的）参与者参与该技术讨论主题。

准备充分的演示者。没有其作者之一或另一位合格且准备充分的演示者来演示的提案，将无法采取行动，也不会在官方会议期间进行审议。我们坚持要求真正的提案人出席有以下几个原因：

  • 演示的目的是让对文档领域（包括约束和考虑的设计替代方案）具有专业知识的人士，向一组通用的 C++ 专家进行讲解。这要求演示者有资格回答有关问题领域中设计约束、已考虑的设计替代方案及其效果等方面的详细问题，其深度是整个小组尚不了解的。

  • 小组讨论的一个主要成果是向作者提供反馈和指导，说明如何改进他们的提案，以便为下次会议创建更新的修订版。演示者必须是致力于提案并确保反馈将被使用的人，这意味着演示者将根据反馈亲自制作新的文档修订版，否则将向作者传达反馈以进行此操作。否则，小组生成反馈的时间将毫无意义。

注意：过去，有时小组主席会尝试帮助寻找演示者。这没有用，并且被积极劝阻，因为实际上这会导致演示者最多只是半熟悉主题，并且没有亲自投入到文档的工作中。

拖延与“抓紧时间”。我们不能在没有文档的情况下采取行动，我们也不会为了等待未来可能获得的替代提案而显著拖延具体提案的进展。如果有一个正在积极推进的提案，并且有人提出异议，认为另一种竞争方法会更好，但该方法尚未有文档，则 EWG 或 LEWG 小组主席可以选择将活动提案的进展推迟一次会议，以便反对者有机会提交按时提交的提案文档。否则，如果竞争替代方案没有文档，它就不存在，并且不会阻止我们面前的提案的进展。

注：在早期讨论阶段，小组主席可酌情允许对积极提案进行有限的替代方案探索，以决定是否需要第二份文档，或讨论正在讨论的文档所暴露的更广泛的先决主题。

有效利用 1-2 年的 TS 滞后时间。如果一个提案有共识进入 TS，但尚未有共识进入 IS，这意味着其进展将延迟大约 1-2 年；这是发布 TS 所需的时间，然后通常需要等待一年，然后才能建议将 TS 合并到 IS 中，并根据 TS 经验进行任何更改。这个窗口是一个有限的“宽限期”，在此期间，任何偏爱与该提案中不同方法的参与者都应积极开发自己的替代提案。不要等待，以为两年是很长的时间；事实并非如此。如果在 TS 准备好考虑合并到 IS 中时，我们没有积极推进的替代提案，默认操作是继续推进我们已有的提案，我们不会无限期地等待更好的东西。

小组职责和投票

小组主席。小组主席由召集人任命，并根据小组的当前需求进行选拔。他们没有固定的任期。

小组讨论。讨论有序进行。希望发言者举手，并得到主席的认可。主席被鼓励在多人排队时保持可见列表。

小组投票。在小组投票中，房间里的每个人都可以投一票。小组主席可以选择进行任何投票。典型的投票类型包括：

  • 全体同意，如果没有异议，则表示每个人都赞成或中立，无需数手。这通常用于在可能已有广泛共识时节省时间。

  • “五选一”投票，选项为：强烈赞成、略微赞成、中立、略微反对和强烈反对。

  • 多项投票，对多个替代方案进行投票（例如，通过五选一投票），以查看哪个方案具有最多共识。鼓励这样做，以免因投票顺序而失去共识最多的选项。

  • 赞成投票，其中有一个替代方案列表，主席对那些“不反对”每个替代方案的人进行一次举手表决。通常，然后在最受欢迎的选项中进行决胜赞成投票。这通常用于讨论命名。

备注

  • 小组投票，尤其是在设计小组中，应有利于进展。通常，如果一个提案的支持者是反对者的两倍以上，在讨论了反对者的担忧并可能重新投票以查看意见是否有所改善之后，该提案就会获得进展。即使有大量人投票中立，情况也是如此，尽管如果大多数投票者都投票中立，这可能会令人担忧。

  • 房间里的每个人都不需要投票（即使是中立）。并非每个人都对每个提案感兴趣，不熟悉特定投票材料的参与者（未阅读文档和/或未密切关注讨论）通常不会对该投票进行投票。

  • 任何投反对票，特别是强烈反对票的人，主席可能会要求他们说明理由。他们应准备好阐明其理由，包括哪些改变会解决他们的担忧并改变他们的立场，或者他们反对以任何形式推进该提案，并且任何改变都不会改变他们的立场。

方向组。方向组是一个由受邀的经验丰富的参与者组成的小组，负责为 WG21 推荐优先级。目前，该小组包括：Howard Hinnant、Roger Orr、Bjarne Stroustrup、Daveed Vandevoorde 和 Michael Wong。其章程包括就以下内容提出小组意见：

  • 演进方向（语言和库）：这包括语言和库主题，以及现有提案和我们没有但应该征求的提案。方向组维护一份其认为对 C++ 下一个版本或在 TS 中取得进展最重要的提案列表，设计组主席使用该列表来优先安排会议工作。通常，其他主题的工作将在本会议上没有更多事情可做以推进列表项之后进行。

  • 对任何特定提案提供意见：这包括是否应继续推进提案，以及如果推进，应考虑进行哪些更改。强烈鼓励设计组成员重视设计组认为足够强烈以建议的意见。

研究小组。研究小组 (SG) 负责“孵化”以产生一份初步提案，然后该提案可以进入常规设计小组处理流程。当某个主题出现广泛兴趣，但尚未形成统一的初步提案可提交给设计小组（通常是因为提案不成熟、不完整和/或相互竞争），并且有强有力的候选人担任 SG 主席以确保其高效运作时，召集人会根据设计小组主席的建议成立 SG。

注意：如需更多信息，请参阅 SD-3：研究小组组织信息。

设计小组。设计小组（EWG 和 LEWG）负责选择和推荐功能设计以及发布载体（TS 或 IS）。注意事项：

  • 讨论应具有建设性，有助于在设计小组内对提案形成广泛的理解，并最终进行投票，为提案作者提供有意义且可操作的反馈，说明是否以及如何改进提案。积极和消极的评论都受到欢迎，但应始终具有建设性和尊重。

  • 如果有人担心某个特定的新提案不应占用过多的分组时间（例如，考虑不周，方向以前没有引起兴趣或共识，或以目前的形式不太可能取得进展），他们应提前私下与分组主席分享他们的担忧。分组主席可以选择（根据此类请求或仅凭自己的判断）加快提案的初步处理，以确保听到代表性概述，然后确定它是否引起了足够的分组兴趣，然后再花时间探索细节；例如，主席可以限定初步讨论的时间，然后投票决定分组是否有兴趣进一步讨论提案的细节。

  • 提案作者应参与设计小组，介绍提案，回答问题，参与设计讨论，并实施小组指示的任何更改，通常是为了在下次会议上审议提案的后续修订。在极少数情况下，如果提案作者选择不实施小组指示的更改，作者应准备好为此决定辩护，并在文档修订中向下次会议提供新信息；不实施设计小组指导的提案会损害其在设计小组和/或全体会议中获得共识的机会。

  • 当提案的设计，经小组主席决定，在其设计和发布方式上获得设计小组的普遍共识时，它将被转发给规范小组。提案作者应与设计小组主席和规范小组主席合作，寻找一名措辞专家，帮助他们起草高质量的规范措辞，然后规范小组审查才开始。

规范小组。规范小组（CWG 和 LWG）负责推荐实现预期设计的“标准语言”规范（又称“措辞”）。注意事项：

  • 提案作者应在规范小组中随时待命，以进行规范更改。

  • 如果规范小组有设计问题或建议，这些问题将转回设计组。

  • 提案作者应参与规范小组，回答问题并实施小组指示的规范更改。

  • 当提案的规范，经小组主席决定，其规范正确表达了预期设计时，它将被转发给闭幕全体会议（WG21 整体）会议。

备注

  • 会议的“意向性投票”wiki 页面将在闭幕全体会议前一晚的当地时间晚上 8:00 更新，以显示所有这些投票（仅由规范小组主席添加到正文中——其他人不应编辑该页面）以及这些投票中提及的所有最终 P-和 N-编号文档（由提案人作为附件添加到该页面）。
  • 为方便起见，规范小组主席将尽力在一周内开始填写意向性投票 wiki 页面。但是，这不作保证，任何想要获取最新信息的人都应该阅读每个规范小组的 wiki 笔记，以查看当前进展，包括哪些项目计划提交全体会议。例如，在 CWG wiki 上，通常搜索“Ready for vote on Saturday”会显示所有已批准的项目。

会议工作优先级。小组主席优先考虑与以下一项或多项相关的文档：P0939 中建议的方向优先级；委员会旨在纳入下一个 IS 的工作；以及本次会议上可在全体会议上取得进展的工作。在此之后，他们会尽力处理其他事项，视时间而定。

全体会议闭幕式职责和投票

演示。主要小组主席介绍他们一周的进展情况。

  • 设计小组主席介绍本次会议批准设计的提案，包括征求所有在场人员表达在小组中可能未发现的任何严重设计问题，以便在投入大量措辞工作之前了解并解决这些问题。批准的设计列表也将添加到会后邮件中的“已批准提案设计”文档的更新中。（注：这是一个新程序，目前尚不存在。每次更新都会创建一个在每次会议上批准的提案设计的累积列表。）

  • 规范小组主席提出将提交的投票。

全体投票。在全体投票中，在 ISO LiveLink 全球目录中列出姓名的每个在场人员都可以投票。召集人可以选择进行任何投票；但是，通常最常见的投票是“三选一”投票，选项为赞成、反对和中立。注意事项：

  • 默认情况是询问是否存在对一致同意的反对意见。（一致同意意味着所有参与者的立场都是赞成或中立，并且没有反对）。大多数投票都以一致同意的方式通过。

  • 如果对全体同意有异议，召集人将进行上述三选一投票。如果存在重大反对，召集人通常会询问反对票是个人立场还是国家机构立场，通常是通过询问在场的国家机构小组主席。

全体会议闭幕式。WG21 全体会议闭幕式负责批准将提案及其规范措辞添加到工作草案（TS 或 IS）。全体会议的职责是决定（由召集人决定）是否就采纳设计和规范小组推荐的每项拟议变更达成共识。全体会议不主动更改设计或进行长时间的设计讨论，这些讨论始终在设计小组中进行。然而，全体会议参与者可以提出问题，例如：“这是否处理了情况 X？”和“您是否考虑了替代方案 Y？”对于此类问题，会议主席将请相关小组主席（他可以邀请提案作者发表评论）回答该项目是否已考虑，并总结讨论结果和小组决定的原因。

全体会议投票还包括提交文件进行正式投票或出版的建议。如果此类投票获得共识，则该文件被视为代表 WG21 当前开发阶段的共识。

技术规范 (TS) 和白皮书

TS 或白皮书是一个实验性分支。在 ISO 中，TS 或白皮书是针对尚未达成 IS 共识的功能。TS 或白皮书是单独发布的“实验性分支”，可以单独发布以获取经验——无论是针对设计的实验性部分，还是为了获得足够的整体经验，使参与者确信整体设计如预期般有效。我们通常不会将工作投入 TS 或白皮书，除非 WG21 喜欢该功能所探索的大致方向，并且会考虑将其合并到 IS 中（可能在经过大量进一步转换之后），如果它最终成功；我们已知不打算放入 IS 的功能不值得以实验形式发布。

注意：一个很好的例子是 Reflection TS。在那里，我们从一开始就知道我们打算将表面接口从模板元编程样式彻底改变为值样式。TS 的目标是获得对该“可换肤”接口底层核心反射能力的反馈。

注：到目前为止唯一的例外是事务内存 TS。在这种情况下，WG21 被要求采用现有的行业规范，并将其修订版作为 ISO TS 重新发布，而不期望将其合并到 IS 中，因为该材料已知是实验性的。

TS 与白皮书：它们功能上相同，但白皮书的 ISO 流程非常轻量级，目前 ISO 和 SC22 均推荐使用。

  • 技术规范 (TS) 经历与国际标准 (IS) 类似的 ISO 投票流程，在 SC22、JTC1 和 ISO/ITTF 层面进行，尽管步骤更少且稍短。TS 受 ISO 最低/最高时间表的约束，需要正式创建 ISO 项目，在技术完成时由 WG21 提交进行正式投票，并由 ISO 整理一轮正式审查意见，必须以《意见处置文件》正式回应，即使在国家机构最终批准后，它也受有时漫长的 ISO 编辑审查和更改的影响，包括遵循 ISO 规定的格式，其中包含书面和不成文规则。
  • 白皮书由我们的直接上级委员会 SC22 采纳；它没有规定的时间表，没有规定的格式，没有 ISO 编辑，并且在技术完成后由 WG21 提交给 SC22，由 SC22 国家机构简单投票批准采纳该草案作为白皮书。

从 2023 年开始，ISO 建议 SC22 的 WG 考虑将白皮书作为一种选项，以避免 ISO 流程瓶颈。

提案与 TS / 白皮书：TS 或白皮书是已发布的产品，而不仅仅是提案。与提案文档（由作者独立维护）不同，TS 或白皮书：

  • 是委员会拥有的文件；
  • 仅根据委员会全体批准投票指示进行更改；
  • 具有更高的措辞质量要求；
  • 作为官方 ISO 出版物发布；并且
  • 解除早期实现者和用户的障碍。

TS / 白皮书与 IS 草案：TS 或白皮书是实验性产品，而非标准草案功能。与 C++ 标准草案中的功能不同，TS 或白皮书：

  • 允许我们解除上一段中提到的进展障碍，即使设计尚未达成共识，当个人和国家机构通常仍有强烈的技术担忧，但暂时愿意在不根据这些担忧进行更改的情况下发布，以换取了解共识差距将在稍后根据 TS 或白皮书的经验得到解决；
  • 被认为是“非规范性”的，因为不要求符合性，且内容可能随时更改；并且
  • 要求实现者/用户提供反馈以识别缺点，并提醒他们预期会发生破坏性更改（他们通常不应在生产代码中依赖该功能）。

启动新的 TS 或白皮书。一旦材料（一个或多个相关提案）达到委员会希望将其转换为 TS 或白皮书的初始工作草案的阶段，并且小组主席已确定召集人可以接受的适当项目编辑，召集人将任命该编辑来维护草案，我们就可以启动一个新的 TS 或白皮书项目。这通过全体会议投票启动，将文档转换为新的工作草案并指示召集人安排 ISO 启动 TS 或白皮书的工作；这两个步骤同时进行，以确保我们永远不会有一个没有工作草案的开放项目（反之则可以）。

注：全体会议意向性投票的措辞如下。

  • 动议指示召集人请求一份关于“C++ 扩展（主题）”的[技术规范 | 白皮书]新工作项目，并创建一份工作草案，其初始内容为[PxxxxRnn“标题 X”和 PyyyyRmm“标题 Y”和...]。

列出具体目标。TS 或白皮书应列出已知需要反馈的具体问题，包括：

  • 我们希望通过此 TS 或白皮书学到什么？
  • 在我们可以考虑将此 TS 或白皮书合并到 IS 中之前，有哪些退出标准（特别是，必须解决的争议问题列表）？

技术规范 (TS) 或白皮书不是一项开放式的探索。它从一个具体的设计开始，旨在回答具体的问题。为了帮助潜在用户，目标部分应概述初始设计的“确定性”程度（而不是一个简单的概述问题空间的草案）以及委员会希望用户帮助回答的问题。这应有助于用户估计使用实现所带来的风险程度，并帮助实现者估计实现所需的工作量（例如，如果对“性能”的理解是 TS 或白皮书工作所需结果的一部分，则实现工作量可能与 TS 或白皮书目标中与“可教性”相关的工作量不同）。

破坏性更改。将功能放入 TS 或白皮书的一个主要原因是允许在标准化之前进行进一步的破坏性更改。一旦功能进入 IS，它基本上就板上钉钉了，并且更难通过破坏性更改进行更新。WG21 从未在没有进行重大更改的情况下将 TS 或白皮书纳入 IS。

将 TS 或白皮书合并到 IS 草案。在考虑将 TS 或白皮书合并到 IS 草案时，通常有两类问题：

  1. 合并后问题，我们已达成共识将 TS 或白皮书合并到 IS 工作草案中，然后处理这些问题；以及
  2. 合并前问题，我们尚未达成共识将其合并到 IS 工作草案中，除非先解决这组特定问题。

合并后问题很可能会在 IS 发布之前解决，但不能保证。合并前问题是指许多参与者会“宁愿 IS 中根本没有该功能，也不愿在未解决这些问题的情况下拥有该功能”。我们鼓励所有参与者将第二组问题保持在最小，仅限于真正的决定性问题，以便我们可以尽早合并 TS 或白皮书，以便在 IS 的完整上下文中进一步完善时进行更好的“集成测试”，并允许标准的其他部分适应新功能。人们和国家机构愿意暂时搁置并 provisional 解决的 TS 或白皮书问题，预计必须解决，可能在合并前；但是，除非出现新信息，否则鼓励人们不要重复讨论 TS 或白皮书启动时已达成共识的决定。

TS 或白皮书可能会失败或保持为 TS 或白皮书。有些实验不会成功，有时 TS 或白皮书可能无法完成，或者只能作为 TS 或白皮书成功。例如，数组 TS 因缺乏共识而被放弃，而事务内存 TS 未整合到 IS 中，因为它不明显 C++ 社区中有足够大的一部分会从它在 IS 中而不是在 TS 中受益。

工作草案处理

批准更新的工作草案。在每次会议的全体会议开幕式上，我们例行地采纳上一次会议后生成的更新工作草案，如下一段所述。会议期间，所有新拟议更改的措辞都将以这些已采纳的草案作为会议的基准。

批准工作草案的更改。在每次会议的全体会议闭幕式上，我们将进行一系列投票，每次投票都要求批准将指定措辞文档或问题列表条目中的更改应用于特定的工作草案。

注：全体会议意向性投票的措辞如下。

  • 动议将[文档或问题编号]应用于[主题]工作草案。

将更改应用于工作草案。会议结束后，每个项目编辑都会生成一份更新的候选工作草案，其中包含所有已批准的更改，并生成一份编辑报告，总结这些更改以及在应用和合并它们时出现的任何其他评论。更新后的草案通常会出现在会后邮件中，但最迟不晚于下次会议的会前邮件。项目编辑可以随时进行编辑性更改，但只能进行全体会议批准的技术性更改。

将草案送审。如果一份工作草案已准备好送审 ISO，并且对草案进行了批准的修改，那么指示召集人送审该文件的投票中，还将指定一个编辑委员会，负责在文件送审前，核实项目编辑是否正确应用了所有批准的修改。

注：全体会议意向性投票的措辞如下。

  • 动议任命由 [...] 组成的编辑委员会，以批准经本次会议批准的动议修改后的[主题]工作草案的正确性，并指示召集人提交经批准的更新工作草案以进行[PDTS|CD|DIS|FDIS 投票或出版]。

当规范小组审查了已应用更改的更新草案时。偶尔，如果规范小组已经审查了整个新的工作草案（已应用更改），而不是描述措辞差异的更改文档，则全体会议投票将按如下方式调整：

  • 要批准更改，而不是投票将文件应用于工作草案，我们进行投票以批准已应用于新工作草案文件的更改形式。（注意：为了程序简单起见，我们仍然像往常一样在下一次会议开始时重新采纳相同的工作草案。）

  • 为了将草案提交投票，不需要编辑委员会，因为已经核实了更改已正确应用。

投票和评论

国家机构和参与。所有 ISO JTC 1 / SC 22 “P”（参与）国家机构都可以派遣经认可的专家亲身参与 WG21 会议，并对投票文件进行投票。国家机构如果希望影响标准的走向，应派遣专家亲身参与 WG21。

注：通常这意味着定期派遣代表参加 WG21 面对面会议。在极少数情况下，如果国家机构是 SC22 P 成员但无法派遣代表参加 WG21 会议（通常是由于严重的经济困难导致他们可以远程投票审查但由于差旅费用无法亲自参加，或由于不可抗力，如政府旅行限制意外变更），他们仍然强烈鼓励参与 WG21 电子邮件列表并在那里提出担忧，而不是等待投票意见。

投票目的和结构。ISO 意见投票是请求国家机构 (NB) 对投票文件中的材料提供具体反馈。它包含两个部分：

  • 对总体的赞成/不赞成进行投票：本质上是“您是否希望这项工作（TS 或 IS）以任何形式继续进行（可能需要修改），是或否？”不赞成（否）票仅应用于表达国家机构根本不希望这项工作（TS 或 IS）以任何形式继续进行——以阻止工作项所有部分的进一步进展。

注意：过去，ISO 曾设有投票解决会议 (BRM)，通过解决国家机构的关键意见可以将“否”变为“是”，国家机构也会报告他们是否改变了投票。我们现在没有这种程序，也没有任何正式机制可以在投票后改变投票。因此，“否”应该意味着“不，我们根本不想要这个 TS 或 IS”，因为足够的“否”票会产生这种效果——如果超过 1/3 的国家机构投“否”票，大多数投票都会失败，因此仅仅为了给国家机构的意见更高的优先级而投“否”票是无效的（我们始终考虑所有国家机构的反馈，而不仅仅是在投票时，并且无论投票中的“是/否”如何），并且会适得其反（实际上可能导致整个项目失败）。

  • 具体反馈意见：无论赞成/不赞成投票如何，大多数投票都可以包含意见。所有关于该文件内容的编辑性和技术性意见都在讨论范围内。意见应包含拟议的解决方案，并附有足够详细的信息以供采取行动；如果所需信息超出意见表可以轻松容纳的范围，则鼓励引用或附上文档。

注意：ISO 及其 WG21 将投票意见视为国家机构的立场。当国家机构提交意见而未事先核实国家机构整体支持所有意见时，就会出现混乱。过去，一些国家机构未经核实就包含了其成员的所有意见，导致收到的意见中包含多数国家机构成员不支持的意见，或相互矛盾的意见。为帮助有序处理意见，鼓励国家机构核实其提交的意见确实是国家立场。

不当的投票意见。因此，有两类具体的意见是不恰当的：

  • 请求添加文件中尚未包含的附加功能的投票意见超出范围。鼓励提出新功能提案，但将其提交 WG21 的正确方式是提交提案文件并努力建立共识以添加该功能。

  • 投票意见要求更改一项已在 WG21 会议上考虑并已作出不同决定的事项，并且该意见来自出席会议并有机会听取和考虑其异议的国家机构，这与 ISO 行为准则中“接受集体决定”的承诺不符。一旦 WG 达成共识将文件提交投票，作为 NB 意见重复之前未能成功的异议，实际上并不是提出新的技术异议，而是对 WG 共识的异议。

注：有两个例外情况

  1. 如果自上次讨论以来出现了足够多的新信息，足以合理地相信足够多的人会改变他们的看法从而影响之前的共识。当然，该信息需要在投票解决会议上提交一份及时文件，理想情况下，该文件应尽早提供并直接在投票意见中引用。
  2. 如果国家机构确实强烈反对某个特定项目，以至于他们愿意对整个 TS 或 IS 的进展投反对票，并且他们一直以来都告知委员会他们感受的强烈程度（参见下文“升级…”）。如果 WG21 不顾这些反对意见而对一份文件进行投票，他们就会知道可能会出现“带评论的反对票”；但是，反对票和负面评论将是针对先前讨论和决定的事项，它们绝不应该作为意外的反对票首次出现在投票中。

投票意见的解决有助于共识的达成。投票意见解决过程中进行的任何技术性更改只有一个目标：提高共识。在最终批准投票成功的情况下，即投票意见解决后文件将直接送交 ISO 出版而无需再次投票，投票与出版之间进行的任何设计更改都应在小组和全体会议上获得近乎一致的同意。这是因为我们需要对设计更改不会降低现有共识有很强的信心，而且我们没有另一次投票来确定更改是否会影响未出席投票意见解决会议的任何国家机构的意见。

如何报告任何严重级别的潜在技术问题

如果您发现潜在问题，请遵循以下步骤：

  1. 保持“潜在”问题的思维定式。通常，即使是经验丰富的参与者也会发现他们发现的潜在问题原来是误解或有充分考虑的理由。保持“潜在”问题的观点极大地改善了所有讨论的语气和成效。
  2. 描述问题，并询问是否已考虑过。如果问题涉及功能提案（无论是已采纳还是仍在进行中），请包括提案作者；作为功能的 डिज़ाइन师，他们将是关于该问题的最佳专家之一。
  3. 如果已考虑过，而您认为与决定存在分歧，请解释如何以及为什么，以及基于什么（实施/部署/用户体验是有用的点）。
  4. 如果未考虑，请再次解释如何以及为什么存在问题，以及基于什么。
  5. 讨论是将其作为问题处理还是需要一份文档。
  6. 提交问题或撰写文档，或以其他方式确保后续工作发生。确保功能的设计者（提案作者）了解后续问题或文档。

请

  • 事先考虑问题的严重程度。是火烧眉毛，还是只是小失误/不便？对谁而言？基于什么？
  • 倾听他人的意见，并考虑他们对此事的观点。即使人们不同意你的观点，也要记住阅读/倾听他们所说的话，并思考原因。

一般来说，这些步骤应该发生：

  • 尽早通知 EWG 和 LEWG 主席以及提案的作者：他们需要了解您的担忧，并接受过问题和担忧的分类和优先级排序培训，并能提供冷静的建议，指导如何继续进行。
  • 尽早通知小组：最好在会议讨论期间，甚至最好在会议之前通过反射器通知。这符合 ISO 行为准则中“及时”的期望。
  • 如果您那时没有注意到，请在意向性投票之前提出。
  • 如果您那时没有注意到，请在会议结束后通过反射器提出。

升级严重的“无法接受”异议或重要的最新信息

如果您认为小组决定犯了严重错误，以至于您认为无法接受其结果，和/或您了解到小组讨论中未考虑的重要新信息，这些信息可能合理地改变其他参与者的看法：

尽早将您的担忧告知 EWG 和 LEWG 主席。如果这是本周做出的并将提交全体会议的小组决定，您应该在本周内积极提出。

  • 在委员会电子邮件列表上：理想情况下，问题应在相关小组讨论结束后立即在该小组的电子邮件列表上提出，但最迟不得晚于全体会议闭幕式前一晚的下午 5 点截止日期（强烈建议在此之前更早发布，最好是在他们认为错误的小组决定之后立即发布）。

  • 在您自己的国家机构内部：这样，国家机构主席就有机会与他们的成员进行党团会议，并确定该立场是否可能是国家立场（通常默认情况下不是国家立场，除非在会议之前或期间讨论过以确定它是国家立场）。

这样，当我们进行全体会议时，每个人都有机会及时了解严重的担忧并加以考虑，当召集人询问您的国家机构主席异议是个人立场还是国家立场时，他们将能够回答。未升级但仍在全体会议上提出或重新提出的异议不应在全体会议上给予重视。（在极少数情况下，如果“就在全体会议前一晚”发现了新信息，它仍然错过了全体会议参与者能够及时给出知情和充分考虑的截止日期，这是一个竞争条件，我们通过声明它未能在截止日期前提出而将其线性化，并且应按照下一项处理，包括后续文件。）

如果截止日期之后（包括会议之间）发现新信息，他们应提出：

  • 在委员会电子邮件列表上。

  • 作为国家机构投票意见。如果参与者未在其国家机构内部提出担忧，并且未能成功说服其党团足够多的人使其成为国家机构立场（通过该特定国家机构小组用来确定此类事项的任何内部规则），则它不会成为国家立场。

在这两种情况下，都应附上包含详细信息的讨论文件（如果最终文件尚未准备好，至少应附上草稿文件）。

其他议题

受保护材料。以下材料不公开，始终受密码保护：

  • ISO 声明版权的文件，特别是 TS/IS 的最终文本。
  • 小组讨论会议记录、会议 Wiki 和非公开委员会电子邮件列表（又称反射器），这些通常包括个人立场和讨论。不允许公开引用这些内容（例如，在文档和博客文章中），但以下情况允许：(a) 引用意向性投票问题和数字结果；以及 (b) 在征得特定人员事先同意的情况下引用其言论或立场。

.结束。