之前参加CSSConf大会，由于对W3C发布流程这些不太了解，故翻译此文，一为了解全貌、加深印象，二为锻炼能人翻译能力，为初学者提供小小帮助。文中难免错误，如有发现，还请回复供我及时更正，以避免误导更多的读者。

用词翻译：

约定：
1. 如无说明，文中提到的“过程”指的是：“TR发展过程”或“REC过程”
2. 如无说明，文中提到的“级别”指的是：“成熟度级别”
3. 如无说明，文中提到的“文档”指的是：“TR文档”

翻译：

7. W3C技术性报告发展过程（TR发展过程）
7.1 成熟度级别
7.1.1 进行中的成熟度级别
7.1.2 REC过程的成熟度级别
7.1.3 TR结束时的成熟度级别
7.1.4 编辑REC的成熟度级别
7.1.5 废弃REC的成熟度级别
7.1.6 针对兴趣小组、协作小组的TR的成熟度级别

7.2 REC过程中推进的通用要求
7.3 评审与评审职责

7.4 推进TR文档到REC的过程
7.4.1 首次发布草案（WD）
7.4.2 LC通告
7.4.3 征求实现
7.4.4 征求PR的评审
7.4.5 W3C REC的发布
7.4.6 打回到起草小组供后续研究

7.5 TR结束时的工作
7.6 修改W3C REC
7.6.1 勘误管理
7.6.2 REC修改的分类
7.6.3 征求对编辑后REC的评审
7.6.4 征求提议REC更正的评审

7.7 废弃W3C REC
7.7.1 提议废弃REC
7.7.2 废弃REC的发布

7.8 TR的相关信息
7.8.1 文档状态小节

为了标准化WEB技术，W3C TR发展过程包括一系列的步骤和要求，本节中讲到的TR发展过程是按照起草小组定义的规范和指导来实施的，包括：
推进TR发展：从草稿到成熟文档（“REC”），称为：W3C REC过程
TR结束时的工作：发布为REC或者放弃发布为REC
修改REC
废弃REC，即：W3C不再支持该REC

设计之初，TR发展过程就是最大化地争取对TR内容的赞同，确保技术性强、编辑质量搞，并提高规范之间的连续性，获得W3C和更多社区的支持。（略）
本文接下来依次描述：
TR发展过程的各个步骤（如：LC通告、征求实现）
每一步的要求
每一步上TR的成熟度级别（如：WD、CR）,请注意TR发展过程和成熟度级别并不是一一对应的。（译者注：如：最后通告LC属于TR发展过程中的一步，但成熟度仍与之前的WD属于同一成熟度级别）

先讲成熟度级别，然后TR发展过程的各步和要求。

7.1 成熟度级别
每一份已发布TR文档的级别代表了它在发展过程中的当前位置。“WD”、“WGN”代表了级别中可能的初始状态，“REC”、“WGN”代表了级别中可能的结束状态。
7.1.1 进行中的级别
WD（草案）
WD指的是W3C发布的一份用于社区评审的文档，这些社区包括：W3C成员、公众和其它技术性组织。部分WD打算推进为REC。参见“文档状态小节”
7.1.2 REC过程中的级别
除了WD，REC过程中的其它级别包括：
CR（候选标准）
如果一份文档已经被广泛评审过并满足起草小组的技术要求。W3C会发布一个CR以获取技术实现上的反馈。
PR（推荐标准）
文档已经通过技术圈的评审和实现，那么W3C就会将文档交给W3C高级委员审阅。
REC（标准）
经过广泛赞同呼声的积累后，W3C REC就会成为一个规范，得到W3C成员、主任的支持。W3C会将其推荐到更多的实践应用中。注意：W3C REC相当于其它组织中的标准。
7.1.3 TR工作结束时的级别
WGN（起草小组意见）
意见由相应的起草小组发布，表示针对该主题的工作已结束。起草方可能会在之前发布的WD之后发布WGN，也可能不会。
注意：在开发社区和媒体中，为了避免混淆：哪个文档代表起草小组的结果、哪个代表W3C活动的来源，W3C已经停止使用不合格的级别：“Note”。
7.1.4 编辑REC时的级别
PER（提议修改标准）
REC的文档修改后，需要经过社区的评审，有一些可能会影响前后一致性。当这些改变得到大家认同时，会发布为PER。
7.1.5 废弃REC时的级别
RR（废弃标准）
REC一旦被废弃，成为已废弃标准，就不再得到W3C支持。
7.1.6 针对兴趣小组和协作小组的TR的级别
W3C也会发布”兴趣小组意见“（"Interest Group Notes"）、”协作小组意见“（"Coordination Group Notes"）。称为“意见”是由于“WD”通常与REC过程关联在一起，W3C会针对这些小组的文档发布“兴趣小组意见/协作小组意见”（"Interest/Coordination Group Notes"）。

7.2 REC过程中的通常要求：
起草小组在WD发展过程中，必须符合以下要求：
1. 记录请求发展过程中的决定
2. 提供与上一个版本修改内容（主要、次要）的所有公开文档。(...)
3. 记录起草小组的修改要求
4. 汇报与其它小组的依赖变更关系
5. 展示广泛评审的证据
6. 正式阐述文档引起的所有问题
7. 汇报任何正式的反对意见

以下信息对于决定是否推进TR非常重要，并且必须可公共访问：
1. TR修改的所有文档（如：除了重大修改的总结外，提供具体“不同”的地方）
2. 发布声明：文档满足所有条件，或者虽然仅满足的部分条件，但仍足以推进文档的合理解释
3. 提供证明：文档已评审、对其它小组的依赖已经解决
4. 针对评审者提出的所有正式问题，均已答复
5. 所有正式的反对

7.3 评审、评审者职责
（略）
7.4 推进TR为REC的过程
W3C遵循以下步骤来推进REC过程：
1. 发布初始WD
2. 发布最后通告LC
3. 征求实现
注意：如果下一步的所有条件已满足，主任可以直接跳过此步
4. 征求PR评审
5. 发布为REC

总得来说，起草小组走这个过程是为了发布REC，然而W3C可能会停止这一工作，也可能会要求小组再进一步探索一下，因此会重复多步。
在首次WD和LC之间，起草小组会发布多次更改的修订版本。LC之后的任何两步之间，如果有重大更改，起草小组会发布一个新的同级别的TR文档，
（译者注：没有读懂原句的最后一句）

针对CR和PR的修订，起草小组必须通知高级委员会。
REC过程可能会持续相当的时间，因此建议阅读该节：“加快REC过程的提示”

7.4.1 首次WD
级别：WD
通告：主任必须向W3C组和公众通告首次WD的发布
目的：首次发布WD后，社区就可以评审文档了。
（略）
7.4.2 最后通告
级别：WD
通告：起草小组必须向W3C组和公众通告最后一次WD，通告必须：
1. 指定评审的截止时间
2. 清楚已知依赖、征求所有独立小组的评审
3. 征求公众评审
（略）
7.4.3 征求实现
级别：CR
通告：主任必须向高级委员会通告征求实现的决定
目的：TR文档已经稳定，并适于实现，基于实现，文档可能会修改；
（略）
7.4.4 征求PR评审
级别：PR
通告：主任必须向高级委员会通告征求评审的决定
（略）
7.4.5 W3C REC的发布
级别：REC
通告：主任必须向高级委员会通告REC的发布
（略）
7.4.6 打回到起草小组供进一步研究
满足以下任何一个情况，TR文档就会被打回到起草小组：
1. 起草小组在LC和REC期间对文档做了重大修改，这种情况下，小组必须重新发布WD文档；如果重大改变指的是：CR阶段去除不易实现的新特性的话，则可以不打回。
2. 主任要求起草小组陈述一些因为评审时、或者由技术实现时提到的重要问题。这种情况下，即使小组没有重大修改，主任都可能要求小组重新发布一份文档作为WD。

如果TR文档被打回，则主任必须通知高级委员会和小组主席。
在WD重新发布后，接下来就是LC阶段了，此时LC可能同时与WD一起发布。
主任可能会要求重新发布为CR，同时征求技术实现。

7.5 停止TR文档工作
TR文档在任何时间都可能停止，当起草小组完成TR时，TR要么是REC，要么是WGN。例如：把TR文档当做多个WD发布，然后该TR文档通过发布WGN表示停止。
如果TR文档没有大的进展，工作可能就会终止。原因可能有：主任关闭该起草小组、参与者失去兴趣、文档主题已经被其它TR文档包含。W3C如果停止该工作，则会发布WGN。

可能的下一步：
结束状态：无期限地处于WGN级别
恢复WD状态：恢复文档到WD级别。

7.6 修改REC
W3C会做好每一步来维护REC，如：勘误管理、提供测试应用、帮助构建测试集，也鼓励广泛的实现。如下讨论了：勘误管理和提议修改REC的流程。
7.6.1 勘误管理
7.6.2 REC修改的分类
本文档区分了以下几种修改方式：
1. 文本内容无修改
如：修复链接、不规范的标记
2. 不影响一致性的修改
如：概念阐述上的修改，不会改变技术性的内容
3. 影响一致性，但不增加新特性
如：
1. 修改保持一致性的数据、处理方式、一致性的实现方到非一致性实现方
2. 非一致性实现方到一致性的实现方
3. 去掉描述不清晰或者未指定的部分，导致实现方从不清晰到实现上的一致性或者不一致性
4. 新特性

前面两个不要求有技术性的评审，第三个则要求如下：
1. 社区评审，确定技术圈无异议
2. 即使发布更新后的REC
第四个必须重新走一遍REC流程。
（略）

7.6.3 征求修改后的REC评审
（略）
7.6.4 征求建议修正的评审
（略）

7.7.1 提议废弃REC
（略）
7.7.2 废弃REC的发布
（略）

7.8 TR文档的通用信息
（略）
7.8.1 文档状态小节
（略）

CSS篇 Process Document第7章 Technical Report Development Process翻译