完整流程
W3C Working Group推进Web技术标准化遵循一系列步骤，叫W3C技术报告开发流程。
w3c process flow
分为标准化流程、后续修改流程2部分，具体见下文。
标准化流程
主要流程如下：
WD -> CR -> PR -> REC
1 2 3 4
从第一份WD（工作草案）开始，经过CR（候选建议书）、PR（提议建议书），最后成为REC（建议书）。REC之前的3个阶段都有反悔的机会：
WD、CR都可以反复确认
CR可以回退到WD
PR本身没有反复确认，但可以回退到CR和WD
成为REC之后，有两种可能的状态变化：
作为编辑建议书（Edited Recommendation）重新发布
被撤销，成为撤销的建议书（Rescinded Recommendation）
另外，W3C可以随时终止整个流程。
标准化的具体流程为：
发布第一份公开工作草案（First Public Working Draft）
[可选]发布几份修订公开工作草案（revised Public Working Drafts）
发布候选建议书（Candidate Recommendation）
发布提议建议书（Proposed Recommendation）
发布W3C建议书（W3C Recommendation）
[可选]发布编辑建议书（Edited Recommendation）
从WD到REC，成熟度越来越高，负责人（Director）可以拒绝向更高成熟度阶段发展，也可以选择回退到低成熟度阶段。
Working Draft (WD)
工作草案是由W3C发布的，供社区review的文档，包括W3C成员、公开的和其它技术机构。
一般来说，工作草案是打算推进到建议书的，工作组的期望见工作草案的文档状态章节。任何不打算或者不再推进到建议书的工作草案都应该发布工作组说明（Working Group Note）。工作草案不一定代表工作组的一致意见，也并不意味着W3C或其成员除了在一般技术领域工作以外的任何认可。
Candidate Recommendation (CR)
候选建议书是满足工作组技术要求，并且经过广泛review的文档。
W3C发布候选建议书有4个作用：
向社区表明该做最终review了
收集实现经验
顾问委员会（Advisory Committee）开始正式review，他们可能会建议把该文档作为W3C建议书发布，回退给工作组进一步修正，或废弃掉
提供根据W3C专利条款（W3C Patent Policy）拒绝的机会。注意：次过程中的候选建议书对应于专利条款中的最终工作草案（Last Call Working Draft）
注意：候选建议书预期被接受为建议书，如果不行，应该注明为什么在这样一个较晚的阶段变更预期。
Proposed Recommendation
提议建议书是已经被W3C负责人接受质量达标（质量足以作为W3C建议书）的文档。此阶段给顾问委员会确定了从候选建议书开始review的最后期限。禁止对建议的建议书进行实质性修改，除非发布新的工作草案或候选建建议书。
W3C Recommendation (REC)
W3C建议书是一项规范或要求，经过广泛达成共识，已获得W3C成员和负责人的认可。W3C建议将其建议书广泛用作Web标准，根据W3C专利条款授予的W3C免版税知识产权许可适用于W3C建议书。
Obsolete Recommendation
过时的建议书是W3C认为不具有足够的市场相关性以支持继续建议社区去实现的规范，而不是说存在需要撤销建议书的基本问题。过时的建议书可能会获得足够的市场份额，这时候W3C会将其恢复为建议书状态。过时的建议书与W3C根据专利政策授予的免版税知识产权许可建议书具有相同的地位。
Rescinded Recommendation
撤销的建议书是W3C不再认可的完整建议书，认为不可能再恢复到建议书状态。
Working Group Note, Interest Group Note (NOTE)
工作组说明或兴趣组说明是由特许工作组或兴趣组发布的，用来给有用的，但不打算作为正式标准的文档提供稳定参考，或者用来记录没有形成推荐书的被废弃的工作。
工作组和兴趣组可能会提供编辑草稿（Editor’s draft），编辑草稿没有官方地位，不代表工作组或兴趣组的一致意见，也不能通过W3C的任何方式批准其内容。
REC修改流程
建议书发布之后可能需要修改（比如勘误，或者大改），需要走修改流程：
// 实质性的变更（大改）
要添加新特性 -> 出第一份WD，从头开始再走整个流程
不添加新特性 -> 经负责人审批回到CR阶段
// 非实质性的变更（小改）
经负责人审批不改
勘误管理
因为对建议书进行错误追踪是工作组持续关注的点，工作组章程许可范围一般允许建议书发布后的勘误工作。
工作组必须对读者和实现者报的错保留记录，此类错误报告的处理频率不能低于每季度一次，建议书的读者要能很容易地查阅特定建议书对应的勘误。
工作组决定怎样记录勘误，最佳做法是一份能够由建议书文本内容确定的文档，并明确指出勘误和任何建议的修正，或者其他含有各种形式的勘误页面的方法，比如从数据库自动生成。
勘误由工作组给出的信息性“提议”修正来解决。经过下一小节描述的建议书修订过程后，修正将成为建议书的一部分。
建议书修订
工作组可以要求重新发布建议书，否则W3C可能会重新发布建议书，来进行不含对规范文本做任何更改的修正。
对建议书的编辑修改不需要对提议的更改进行技术审查，如果发布决议没有反对票，工作组可以要求发布一份建议书，否则W3C可能会发布一个建议书来做这种变更，而不会经过早期的各级成熟度，此类发布物叫编辑建议书（Edited Recommendation）。
对有实质性变更但不添加新特性的建议书做修正，或者有投票反对直接发布修正案作为建议书的话，工作组可以要求发布候选建议书，不用经过更早的成熟度级。
后两种情况下，所得到的建议书叫做编辑建议书。
在请求发布上一节提到的编辑建议书时，除了满足相关成熟度级要求外，工作组还：
必须表明文档变更已经经过了广泛审查
应该解决所有记录的勘误
对于那些引入了新特性的变更，W3C必须从新的第一份工作草案开始，遵循把技术报告推进到建议书的完整过程。
