Design Docs の話。自分が思ったことは言い尽くされていた。

この一か月くらい合意形成のために一連の文章を書いており、個人的に関心のある話題だった。公かつ現在進行形だし、ということで思いついたことをつらつらと書いてみる。

前提として、ブラウザに Web 標準にかかわる機能を追加するには公で議論する必要がある。Explaner や Design Docs といった体裁の差はあれ、意図を文章に書き下すのは必須になる。この時点でこの手の文章を書くべきかどうか、を議論する選択肢はなくなった。悲しい。個人的には書かなくて済むならそうしたいところ。

Chromium のテンプレートには意図的に従っていない。これは強制されなければ好きなように書けばいいのでは、と思っていたから。当初は Standardization やら Considerations やらのセクションは無く、専門家から突っ込みを受けて追加した。ここは、はまじさんがいっていた、デザインの根幹にかかわる指摘を専門家から受けた事例かな、と思う。実際有難かったし、テンプレートには意味があるなあと思うところでもあった。現時点では Metrics のセクションもない。LCP を改善できるかも、とは書いているが具体的な比較手段を言及する必要がある。現状が許されているのは、件の文章は Intent to Prototype として書かれたもので、とりあえずやってみよう、という段階だから。

なぜそれをやるのか、は意識して書こうとしたのだけど、いろいろと修正していったら焦点がぼやけてしまった。なにをやらないのか、が無いのもその帰着。合意をとるのを重視したのが出ている部分だと思う。

Design のセクションの有用性は半々かなという印象を持っている。このセクションは Proof of Concept なコードをまず書いて、ある程度動く見通しを立ててから文章に落とし込んでいる部分が多い。ただ、alternatives を列挙しているトピックについてはパッチを書く前に合意をとるのに役立ったし、事前にフィードバックをもらうことで解決した問題もあった。

1 つ具体例を挙げる。ネットワークからの信頼できない情報を処理するのに、当初は権限の強いプロセスを使うことを想定していた。これはセキュリティ的に懸念があり頭を悩ませていた部分だった。お茶を濁すような文章を書いていたら、緩和策として分離された別のプロセスで処理する既存の機能を流用できることを教えてもらった。意図を文章で書くことで得られた次善案だった。

Design セクションの後半は TODO: あとで考える が多い。これはもりたさんのいう、決まってないところは無理に書かず、インクリメンタルにアップデートする、という考え方を実践してるのかもしれない。前段で問題のスコープに関して同意をとれていれば詳細について TODO を多用してもだいたい許されるように思う。裏を返せば前半に TODO が少ないのは実装が既に終わっているから。実装し終わった後に TODO を消して実装に合うように記述を修正している。

最後にこのエントリを書いている時点での進捗と進め方について。今はあるトピックについて Work in Progress なパッチを育てている。並行して、今後の大まかな方針について意識を合わせるためのドキュメントを書いている。ここでもコードが先行し、文章が後追い、という感じ。数か月後に振り返ってみて、どう帰着したか見てみると面白いかもしれない。

自分の書いたドキュメントは我ながら稚拙だなあと思う一方、一定の役割を果たしているのならそれでいいか、と割り切って書いている。