若干テンション高めというかフレンドリーというかそんなニュアンスで訳しました。Hixie の意図するニュアンスとは異なる可能性がありますがご了承ください。
誤訳の指摘はコメント欄や Twitter で @dynamitter 宛にお願いします。

原文: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jul/0119.html

HTML 仕様策定にここ数年 W3C が参加していたのを無視してこれた人は読まなくてオーケー。大量のバグメールが飛んできたけど何でだ？と思った人は続けて読んでね。

当時僕らが公式には “Web Applications 1.0″、裏では “HTML5″ って呼んでた仕様について W3C と共同作業を始めたのは今から数年ほど前 (2007 年頃) だった。僕らは仕様の名前を “HTML5″ と変更し、W3C もそのコピーを公開するようになったんだ。すると程なく、W3C では標準をいくつかの標準に分割したから (つまり、2D Canvas API, Server-Sent イベント、postMessage とかにね)、WHATWG 側でもそれに合わせるよう努力してみたんだ。けれど複数バージョンの仕様があることで混乱し、結局 WHATWG 側では僕が担当するすべてをまとめた、1 つの仕様だけに戻すことにしたんだ。僕らが今 “HTML Living Standard” って呼んでるやつにね。それから数年、この文書と W3C 側のいろんな文書はちょっとずつフォークしていったんだ。WHATWG 標準の冒頭 (訳注: 多分ここのこと) で書いてるようにね。

最近になって、HTML 戦線における W3C と WHATWG の目標もちょっとずれてきた。WHATWG では HTML や関連技術の正確な説明を作り上げることに集中してきた、つまり、バグは見つけたらすぐ [1] 直し、新しい機能は必要になったり使えるようになったら追加し、実装も追いかけてきた。その間 W3C はご立派な W3C 標準化プロセスに従ってスナップショット作りにいそしんできたんだ。そして遂に W3C ワーキンググループの議長達と僕は作業を 2 つに分けることにしたんだ。W3C HTML5, Canvas, Microdata 仕様の執筆に責任を持つ人と WHATWG 仕様のエディタ (僕) は別にしようってね。[2]

W3C と一緒にやっていく中で、僕らは WHATWG 仕様右下のウィジェットで登録されたバグを W3C の Bugzilla システムで管理してきた。W3C は WHATWG 仕様に対して登録されたバグのホストを快く続けてくれていたんだ。これまで W3C と WHATWG の仕様を両方を一人のエディタが担当していたから両仕様のバグを 1 つにまとめて、僕は仕様は 1 つしかないかのように処理してこられた。でもフォークしちゃうと (訳注: エディタが別になると) それは続けられない。だから、W3C の Bugzilla システムで HTML 仕様に登録されていたバグをすべて取り出して複製したんだ。1つは W3C 用に、もう一つは WHAWG 用にね。僕は WHATWG のバグを扱っていき、W3C の新しいエディタ(達) [a] は W3C のバグを扱っていく。もし君が最近大量の “operation convergence” って書かれたバグメールを受け取っていたら、そういうことさ。具体的にどうなるんだってことはこのメールに続けて書くね。

僕にどんな影響があるの？

* WHATWG の仕様にフィードバックを送るなら、このメーリングリスト (whatwg@whatwg.org) に送ってくれるのが一番簡単だよ。

*WHATWG の仕様のバグを報告するなら、WHATWG 仕様に付いてるツールを使ってくれれば適切なコンポーネントを選んでくれる。

*W3C Bugzilla を直接使ったり WHATWG 仕様のバグを検索したいのなら、Bugzilla で “WHATWG” プロダクトを選択してくれ。僕が編集してる仕様のコンポーネントは “HTML” だよ。他のコンポーネントは Anne とか他のエディタが編集してる仕様のためのものだからね。

*Bugzilla にコメントを書いて僕に読んで欲しいのなら、僕に割り当てられてるバグにコメントしているか確認してね。”WHATWG” プロダクトじゃなくて “HTML WG” プロダクトのバグは HTML WG のエディタに割り当てられているもので、多分僕は見ないから。(もちろん僕も W3C 側の変更をできる限り追い続けるけど、個別のバグコメントまでは目を通せないと思うんだ。)

WHATWG HTML 仕様で現在未解決のバグはこのリンクで確認できる:

https://www.w3.org/Bugs/Public/buglist.cgi?product=WHATWG&component=HTML&resolution

フィードバックがどれくらい溜まってるか確認するには、僕はこのグラフを見てる:

http://www.whatwg.org/issues/data.html

“operation convergence” についての詳細:

これまでバグには2つのバケツがあったんだ。(“HTML5 spec” とかいろんなコンポーネントの) W3C 仕様に登録されたバグと、(“other Hixie drafts” コンポーネントの) WHATWG 仕様に登録されたバグがね。その殆どは僕に割り当てられ、コンポーネントなんて気にしてこなかった [3]。

僕は最近 W3C スタッフと協力して 2 つのスクリプトを走らせて、バグを全部複製したんだ。1つ目のスクリプトでは “HTML5 spec” コンポーネントにあったバグを選択して、複製したバグを WHATWG プロダクトに登録して僕に割り当て、元のバグは nobody に割り当てた。2 つ目のスクリプトでは “other Hixie drafts” コンポーネントにあったバグを選択して、”WHATWG” プロダクトに移動させ、”HTML5 spec” コンポーネントに複製し、nobody に割り当てた。今回 nobody に割り当てられたバグはそのうち W3C の HTML5 仕様エディタになる誰かに割り当てられることになるだろう。今後登録されるバグには何も影響しない。これから先に進むため、長期的な計画をどうしていくか、僕はこれからも HTML ワーキンググループの議長達と一緒に決めていく。古い “other Hixie drafts” コンポーネントは無くしたよ。

ここで書いたことは、4月にアナウンスした WHATWG は W3C コミュニティグループ になるって件とは関係ないんだけど、要するに、W3C の HTML ワーキンググループからは独立するけど W3C との協力関係は保たれるってことさ。[4]

最終的な結果としては、HTML Living Standard の策定作業が再び加速され、W3C ワーキンググループと共同作業を始める前のペースを取り戻せることを、僕は期待している。

質問があるなら、僕に直接メールするか、IRC チャンネル (Freenode の #whatwg)で聞いてね。技術的議論の S/N 比を保ちたいから、このメーリングリストでは仕様策定プロセスに関する議論はしないで欲しいんだ。

— 脚注 —
[1] あるいは、見つけてから数ヶ月後にね… 今僕は 6 ヶ月ほど遅れてる。ゴメンね。頑張るよ！ (・・).

[2] http://lists.w3.org/Archives/Public/public-html/2012Apr/0204.html

[3] 詳しく書くと、僕は W3C HTML WG コンポーネントのバグについては “Accepted” や “Rejected” として閉じるブックマークレットを使っていた。HTML ワーキンググループのプロセスで要求される雛形があったからね。”other” コンポーネントのバグについては雛形なんて使わなかった。HTMLWG のプロセスを経る必要があるのは彼らのバグだけだったから。

[4] http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Apr/0240.html

[a] 訳者追記: W3C 仕様のエディタについて、Canvas 2D などのエディタは未確定ですが HTML5 のエディタは Travis Leithead, Erika Doyle Navara, Ted O’Connor, Silvia Pfieffer になったようです: http://lists.w3.org/Archives/Public/public-html/2012Jul/0183.html

— Ian Hickson

訳者コメント

今回の件で「WHATWG と W3C が決別して HTML5 がフォークした！」と騒ぐ人もいるかと思いますが、そんな話ではありません。フォークって言葉を強調した記事に釣られないようにしましょう。

プロジェクトやツリー全体がフォークするのではなく、安定バージョンのブランチを切ってブランチ専用のメンテ担当者を割り当てましょうって話が進んでいて、バグ管理もトランクとブランチで分けるようになったんだと理解するのが正しいかと思います。普通の製品開発でも安定ブランチ作りますよね？

Hixie の期待通り再び HTML の仕様策定が加速され、Web がより魅力的なプラットフォームになることを期待しています。(・・).