摘要

  • Mozilla 的2020 年 10 月说明承认，旧 Wiki 的修改先发布，不合适的内容再撤回；Yari 要让拉取请求先接受审核，公共页面随后才改变。
  • 12 月 14 日上线公告确认，文档从 SQL 数据库迁为 GitHub 仓库文件，初期仍是 HTML。首页、个人资料和搜索当时还运行在旧的 Django 系统上。

按下保存，读者就先看见

Wiki 把一个尖锐的问题交给了保存按钮：谁有权先说“这一行就是 MDN 的答案”？旧流程里，贡献者打开可视化编辑器，改完页面，修改便进入公开文档。管理员可以事后回滚。Mozilla 在2020 年 10 月 29 日的迁移说明中坦承了这套顺序。

它适合改错别字。它也给垃圾内容同样快的通道。对于认真写作的人，事后审核还有一层沉默：编辑留下来，像是被接受；被撤掉，贡献者可能只有重新打开页面才知道。Mozilla 认为这种“先见报，再擦掉”的相处方式不利于建立社区。它给了人们发表的速度，却没有在作决定时给出充分交流。

这套编辑方式还影响着读者看不到的服务器。文档放在 MySQL 中，Mozilla 自己维护版本历史、差异展示和回退等功能。读者与作者经过同一套平台。为了让作者的修改尽快显现，CDN 缓存保持五分钟。Mozilla 说，超过 99% 的流量是读者请求文档。少量写入操作所需要的即时性，改变了绝大多数读取请求走的路。

拉取请求先到，公共页面后到

Yari 改变的不只是数据库位置。作者要在 GitHub 仓库里改文件，提出拉取请求，等人审阅、讨论、合并；新页面经构建与部署才呈现给读者。Mozilla 的10 月计划设想每天部署，并把最坏情况下的上线时间定为投稿后 48 小时。这是发布前的目标，不是每次修订实际耗时的统计。

机构从中得到一扇有记录的门。审稿人可以在文字上站之前指出问题，贡献者可以在请求下解释或修改。一次拉取请求能覆盖多页，自动检查也可以插在合并之前。垃圾内容不必先出现在公共文档，再由管理员追着清除。Mozilla 同时希望摆脱大量自建 Wiki 代码，把给读者的页面预先生成。审核从“事后扫地”变成了“进门验票”。

验票也有代价。只想修正一处笔误的人，不能再打开内嵌的所见即所得编辑器点保存。Mozilla 承认，GitHub、拉取请求、合并和部署让简单改动多走几步。GitHub 网页本身能处理小修订，不一定要求命令行，但编辑者仍得面对仓库中的源文件。更容易被后来的记忆弄错的是格式：Yari 上线时，这些文件存的是 HTML；Markdown 只是未来计划。

文档搬了，旧楼还在用

Mozilla 11 月 2 日开始测试新平台，12 月 14 日宣布正式上线。写文档的人改为向官方 mdn/content 仓库提交拉取请求。文档内容离开 SQL 数据库，但首页、个人资料页和搜索仍由旧的 Django 服务承担。所谓“平台迁移”并非一个夜晚拆掉整座楼；先搬走的是公共文档的编辑和发布路径。

随后，2021 年 7 月的 Mozilla 公告说，MDN 账户不再用于贡献内容，编辑者必须登录 GitHub。Mozilla 计划 7 月 22 日停用 MDN 账户功能。审核工具的账户系统由此也成了进入编辑流程的入口。你仍能提出修订，但必须从这扇门进来。

前后两套制度都能称自己欢迎贡献，权力分布却相反。旧 Wiki 让贡献者先把话写给读者，Mozilla 负责撤回；Yari 让贡献者先把话写给审稿人，审稿人掌握何时合并并推给读者。对于只来查一个 API 参数的人，这种改变可能不显眼。对于想纠正那个参数的人，决定公共答案的手已经换了位置。