要約

  • Mozillaの2020年10月の説明によると、旧Wikiでは編集内容がすぐに公開され、不適切なら後から取り消された。Yariはプルリクエストを公開前に確認する順序へ変えた。
  • 12月14日の開始告知は、文書がSQLデータベースからリポジトリのファイルへ移ったと記す。開始時の中身はHTMLで、ホーム、プロフィール、検索のページは旧来のDjango基盤に残った。

「保存」が最初の編集判断だった

技術文書の誤記は、早く直せるほど助かる。以前のMDNでは、閲覧中のページから視覚的な編集画面を開き、書き換えて保存できた。その時点で文面が公開され、運営側が問題を見つければ差し戻す。Mozillaは2020年10月29日の移行説明で、この「まず掲載、必要なら撤回」という仕組みを明記している。

この速さは善意の訂正だけのものではなかった。スパムも審査前に読者の前へ出る。協力者への応答も薄い。修正が残れば採用されたらしいと推測できるが、消えた理由を知るには自分でページを見直すしかない。Mozillaは、黙って受け入れるか黙って取り消す関係を、協力者との交流に向かないものと見ていた。公開する権限を先に渡し、説明する場を後から探していたわけだ。

運用側の費用もあった。文書はMySQLに保存され、改訂履歴や差分を扱う仕組みをMDN側が保守した。執筆者と閲覧者は同じ基盤を使い、CDNのキャッシュは五分に設定されていた。編集を早く反映するためでもある。Mozillaによれば、アクセスの99％超は文書を読む要求だった。少数の編集をすぐ見せる設計が、大多数の閲覧要求を支える構造にまで及んでいた。

先に公開されるのは提案になった

Yariでは文書の修正をGitHubのファイルに書き、プルリクエストで提案する。担当者が読んで意見を交わし、マージした後にビルドと配信が続く。公開文書は提案のあいだ旧版のままだ。Mozillaの10月の計画には、日次配信と、投稿から公開まで最悪でも48時間という目標があった。これは開始前の目標であり、全修正の実績値ではない。

審査の場所ができれば、変な文を出す前に直せる。協力者は取り消された理由を推理する代わりに、提案の中で説明を受けられる。一つの提案で複数ページを修正し、自動検査を走らせることもできる。Mozillaは、Wiki固有の履歴管理コードを減らし、読む人には事前に生成したページを届けようとした。公開後の清掃作業が、公開前の編集判断に変わった。

ただし、短い訂正をしたい人の道は長くなった。ページ内のWYSIWYG編集画面はなくなる。GitHubの画面ならコマンドラインを使わずに小さな変更を出せるが、ファイルを直して提案し、マージと配信を待つ必要はある。さらに12月の開始時点、文書の保存形式はHTMLだった。Markdownへの移行は将来の構想であり、Yariの初日から使える新しい書式ではなかった。

新しい入口と残った旧基盤

Yariの試験運用は11月2日に始まり、Mozillaは12月14日に公開開始を告げた。以後、文書の変更は公式のmdn/contentリポジトリへ出すプルリクエストになった。一方、ホーム、プロフィール、検索はなおDjango側にあった。「データベースからGitHubへ」という説明だけでは、移行の境界がぼやける。読者向け文書の制作経路が先に移り、周辺のサービスは残った。

翌年の2021年7月の告知で、その経路にもう一つ条件が加わったことが分かる。MDNアカウントは投稿には使われなくなり、文書を編集するにはGitHubへログインする必要があった。Mozillaは7月22日にMDNのアカウント機能を止める予定だと述べた。提案できることと、どの身分証で提案の入口に入るかは、別の問題である。

旧Wikiでは執筆者の保存がまず公共の文になり、MDNが後から撤回できた。Yariでは執筆者の提案がまず審査の対象となり、マージする側が公共の文になる時点を決める。閲覧画面だけを見れば小さな変更かもしれない。誤りを見つけた人にとっては、その一行を直す権限の位置が変わった。