W3C 規範制定流程

完整流程

W3C Working Group 推進 Web 技術標準化遵循一系列步驟，叫 W3C 技術報告開發流程。

[caption id="attachment_1451" align="alignnone" width="466"] w3c process flow[/caption]

分為標準化流程、後續修改流程 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 必須從新的第一份工作草案開始，遵循把技術報告推進到建議書的完整過程。

參考資料

World Wide Web Consortium Process Document