这是提案从“酷点子”到“国际标准”的进展总结。

提案必须经过两个主要级别：获得“设计”组（演进工作组，即 EWG；和/或库演进工作组，即 LEWG）以及“措辞”组（核心工作组，即 CWG；和/或库工作组，即 LWG）的批准。以下是概述，其中底部“将工作纳入 C++ IS 主干本身的标准”只是一个粗略的指导建议，将根据人们对提案的接受程度而有所不同。

每个提案都要经过多个阶段。提案越小、争议越少，进展越快，可能在一个会议中完成多个阶段。提案越大或争议越大，处理越谨慎，一个阶段可能需要多次会议（尤其是阶段 2、5 和 7）。

0. 酷点子发布到博客、邮件列表、Reddit 等。（大多数提案从未通过此阶段。）

1. 提案人提交一份初步设计文件，并请求向设计组展示。文件包括动机、考虑的替代方案、具体示例以及足够详细的具体提案以供评估。

2. 设计组同意他们对该领域感兴趣并寻求探索此一般功能，并要求修订。（一个独立的提案通常在多次会议上迭代以完善设计。如果有相互竞争的提案，迭代和收敛需要更长时间。如果需要大量迭代并且可以在会议之间的额外面对面或电话会议中完成工作，设计组主席可以建议为该主题启动一个研究小组，以生成一个合并的初始提案，并将其带回设计组。）

3. 设计组同意追求一个特定的精细设计方向，并要求提供初步措辞。

4. 设计组批准初步措辞，并转交措辞组。

5. 措辞组审查和完善措辞，同意其已准备好纳入工作草案，并将其转交全体委员会。

6. 全体委员会同意将措辞纳入工作草案，并创建问题列表以跟踪问题。（如果工作要放在其自己的 TS 中，这将是新 TS 的初始工作草案。）

7. 设计和措辞组处理设计和措辞问题以完善规范，并将每次更改转发给全体委员会批准。（措辞必须正确表达批准的设计；任何关于特定代码示例含义的问题都必须在设计中解决并反映在措辞中；措辞必须清晰，以便实现者知道要实现什么，并且程序员可以编写在不同实现上以相同方式运行的可移植代码。）

8. 全体委员会将工作草案发送出去进行委员会之外的国际意见投票，几个月后投票意见反馈给委员会。

9. 设计和措辞组解决投票意见，并将每次更改转发给全体委员会批准。

10. 全体委员会将工作草案发送出去进行最终批准投票和/或发布。

11. 如果提案首先在 TS 中发布，那么在获得 Beta 反馈后（通常包括供应商实现该功能和用户尝试该实现的经验），有人将提议将其纳入 IS 工作草案，可能根据使用反馈进行更改，并在设计和措辞组中进行设计和措辞稳定性评估后，重复阶段 6-10，以达到“IS 质量”（通常比第一次快得多，因为大部分工作通常已在 TS 中完成）。

概念与误解

请注意，存在两个常见的错误或至少是误解

• 许多委员会以外的人认为他们在阶段 0 或 1 就完成了，并认为委员会会直接采纳他们的想法。除非有详细的设计文件，并且有一个提案人会亲自向委员会展示并为之贡献工作以纳入反馈并完善提案，否则不要期望任何事情会发生。
• 新的提案人倾向于认为他们在阶段 4 就完成了并宣布胜利，认为措辞组会直接“实现”并“做正确的事情”。导致这种错误的常见心态是认为提案现在已经“完成了 80%”……从设计的角度来看这可能是真的，但剩余的阶段构成了“另外 80%”（只是说说而已！）的必要工作，以实际将其进一步推进，直到成为高质量、详细且可实现的已发布规范。——而当我们对“差不多完成”的功能在“一年左右”就能发布过于乐观时，通常是因为我们忘记了阶段 5-10 的实际成本和延迟。

经验丰富的提案人明白，他们必须亲自保持参与并贡献大量工作，直到并包括阶段 7，然后才能谨慎地宣布胜利，同时在剩余阶段仍然仔细关注与其提案相关的投票意见。