亲们，这篇长文具体描述了知识库具体是如何运作的。这篇长文很长，连目录都不短，你们要有心理准备。

知识库是维基的升级版

看看这些先：

• 特别的维基标记语法 - 虽然我们总体上用的是 MediaWiki 标记语法 (就像维基百科)，我们的知识库还是针对Firefox 技术支持具体优化和设计过了的，有一些特别的语法(例如 {for} 标记)以便给使用不同操作系统/Firefox 版本的用户展示相应的帮助文档。
• 审核系统 - 为了让用户看到与时俱进的帮助文档，所有文档的修改都需要经过审核才能发表。
• 翻译系统 - 有一大部分 Firefox 的用户使用英语之外的语言，所以我们的网站也有一套完备的翻译功能以把技术支持信息本地化为各种语言。

访问知识库的用户和他们的知识背景

想想看我们有超过4亿的用户，你就明白知识库的文章必须要写得通俗易懂，而不能只针对电脑行家们。我们也只能优先撰文解释那些用户最为关心的功能（例如标签页浏览，书签和同步）和问题（例如崩溃和网站打不开）。 至于别的问题，我们会通过用户的反馈（文章后面的讨论，用户支持论坛，实时聊天和文章的查看次数）以及我们的经验来决定是否撰文。

我们应该避免在知识库撰写哪些文章？

• 修改 Firefox 的一些高级/隐藏技巧
• 只有开发人员才会关心的信息和高级功能例如错误控制台和网络控制台

组织好我们的工作

优先处理哪些内容？

我们按照人气指数来处理文章。 因为这是用户的选择。当前排名前25的文章几乎占总点击率的一半。换句话说，这些文章的受众和后面100篇文章的受众数目是一样的，我们当然要优先把这25篇文章维护好。贡献者控制面板中的文章也是按人气指数排名的，在开始工作前你就心里有数。

例外：
不过人气指数显然也不是唯一的标准。我们也得考虑到下面的例外情况。

• 有潜力的文章 - 有时我们会更新一篇文章来描述一个新功能或者功能变更。这篇文章可能尚未获得很高的点击率，但是按照经验和营销计划，它早晚会获得足够的人气。
• 重大问题 - 反复在支持论坛或者实时聊天被提到的新问题也需要及时更新知识库文章。
• 移动版、Sync 和 Firefox Home 的支持文档 - 这些产品的用户数跟桌面版 Firefox 难以相比。相应文章的更新不应根据点击率来决定，而是需要具体情况具体分析。
• 链接的文章 - 这些文章可能在产品内部链接或者链接到 mozilla.com 。

在哪里讨论文章？

我们一般在两个地方讨论知识库文章：

• 具体的文章页面 - 每篇文章都有自己的讨论页。注意用户可以在此发布反馈，比如文章需要如何修订，修订版本的优劣和问题等等。
  
• 知识库整体讨论 - 关于知识库整体的策略、政策和软件问题在知识库文章论坛讨论。

我们如何让知识库文章跟上最新版 Firefox ？

目前有四个版本的 Firefox 位于不同的频道（Channel）：Nightly （每夜版）、Aurora（曙光版，内测版）、Beta（公测版）和 Release （正式版）。它们每六周前进一个频道。具体对某一个版本来说，在前六周之内新功能和新补丁被添加和应用到 Nightly 版中；然后移动到 Aurora 频道进行六周测试，然后再花六周时间在 Beta 版测试，之后才能正式发布。相应地，知识库文档也需要采用这样的六周循环。

文档周期 1 至 4

• 为 Beta 版进行翻译：在上一周期被定稿的文章（英文原文）有四周的时间进行翻译。我们把英文原文标记为"送交翻译"以通知翻译人员。
  • 注意：在此之前的两个星期，根据上一正式版的反馈，我们也会更新英文原文，这些更新将一并被送交翻译。
• 为 Aurora 版写初稿：我们有4周的时间写新文章以及更新现有文章。我们根据发布跟踪页面来决定哪些更改和新功能需要支持文档。
• 跟踪 Nightly 版：我们根据发布跟踪页面来决定哪些更改和新功能需要支持文档。在正式版发布前，对Firefox 功能的跟踪是一个永不停息的过程，但是一旦进入了 Aurora 频道，一般就只有删除某功能才算是主要的变更。
• 文章归档：发布新版本也意味着 Firefox 软件和技术支持文章都会需要更新，这时我们就可以看看有没有哪些文章
  • 随着 Firefox 的改变变得过时了；
  • 逐渐没有用户查看（大部分用户不再碰到此问题）从而变得过时。

文档周期 5 & 6

• 为 Release 版更新文章：新版要发布时，我们有必要根据用户的反馈再做一些调整和修改。
• 为 Beta 版定稿：当 Aurora 移动到 Beta 频道时，我们有两周时间把文章定稿。这个过程中：
  • 添加必要的截图和视频演示。
  • 审批文章。
  • 把定稿标记为送交翻译
• 开始跟踪新的 Nightly 版：下一个开发周期又从 Nightly 频道开始了。

我怎么跟上 Firefox 的开发进程？

• Firefox 技术支持 (SUMO) 博客：最新的更新进展都可以在这里看到。
• 贡献者主页：每周更新，值得常看看。
• SUMO 社区的讨论：贡献者在这里进行交流。

完善文档

我们90%的时间在完善知识库文章。在这 200 多篇文章里总有需要改进的，总的来说有三种方法：

• 保持与时俱进 – Firefox 重要的版本更新会带来新功能和新改变。我们在这里写的内容当然应该跟用户手头上的产品相一致。
• 校对文章 – 有些人的眼力好，一眼就能看到一些语法和拼写错误（相信你也在前文中发现不少吧？），那就请你不要客气咯！
  • 修改拼写，语法和标点。
  • 修改标记语法和格式错误。请参考 怎样编写技术支持文章, 如何使用For语句 以及 如何使用模板。
• 把文章写得清晰易懂
  • 把晦涩的知识用浅易的语言重新解释一遍。
  • 有图有真相！有了截图，用户可以更清楚地明白什么是地址栏、搜索栏，而不是混淆成刘翔跨的那个栏....
  • 有视频演示就更给力啦！就仿佛你抓着用户的手在操作鼠标一样。

编译文章的流程是怎样的呢？

简而言之，你只要点"编译文章"，进行修改后提交审核。完整的流程是这样的：

1. 打开贡献者控制面板。
2. 点击一篇文章以查看历史版本，这样你就知道该进行什么修改。讨论页的信息也有很大的参考意义。
3. 编辑文章。关于排版的知识可以参考How to write knowledge base articles。
   • 使用预览按钮来预览你的修订成果。
4. 点击提交以供审核来保存你的修订成果。你的修改成果会出现在贡献者控制面板中"未审核的更新"一节。

如果你的修订迟迟未被审核，你可以在#sumo IRC 频道上或者通过 电子邮件联系 michaelverdi 。

如果你的修订被退回（待定）了，审核人会给出理由（出现在相应文章的讨论页上）。有时或者他们已经基于你的修订加上了他们自己的更新，从而生成了一个新的修订。

接下来有可能不同的贡献者完成了几轮次的修订，文章才达到一个不错的质量。

新建一篇文章

如果你想把一篇文章加入知识库，请这样做：

1. 新建一篇文章 并参考某篇已有的文章填写相应的表单。
2. 完成文章内容。
3. 使用预览按钮来预览
4. 点击提交以供审核按钮并注明撰写这篇文章的原因。
   • 这样该文章就推送到知识库控制面板以待审核。
   • 审核通过后该文章才会被公开发表。

文风

Firefox 技术支持应该让所有 Firefox 用户受益而不仅仅是电脑高手。

• 你要想想如果不描述清楚具体的步骤，你的读者很可能无法添加某个工具栏按钮或者改变某一项设置。
• 你要假定你的读者使用的 Firefox 或者操作系统是默认设置。
• 对话风格 – 使用积极的对话风格来撰写文章，就像你在读者面前与之交流一样。
• 截图和视频演示 – 这两种信息和文字配合使用效果极佳，读者也会对具体的操作印象深刻。

更多信息请查阅怎样编写技术支持文章。

标记语法

我们的支持网站使用 MediaWiki 语法并专有一些排版用的按钮，快捷键和菜单。具体列表和例子请查阅翻译标记表。

语法

如何使用For语句一文中具体介绍了如何针对用户的操作系统和 Firefox 版本展示不同的支持文档内容。

模板

模板页面中列举了可用的模板。使用模板的好处是同样的片段可以方便地被重复使用，一旦需要修改，也只需要修改模板就可以让所有包含该模板的文章都得到更新。 如何使用模板 一文中有具体介绍。

截图和视频演示

我们要确保支持文档即便没有图片和视频也可以被看懂。截图和视频演示是很有用，但并非强制使用。在翻译的过程中翻译人员也可以根据需要添加和删除它们。

操作系统优先级

1. Windows - Windows 用户占总用户数的 90%，其重要性不言而喻。我们现在使用 Windows 7 系统下的截图。在添加关于 Windows XP 的支持时要具体截图。
2. Mac - 当前最新版是 10.7 (Lion).
3. Linux - 使用 Ubuntu 下的截图。

移动设备

1. Android - 2.2 Froyo. 当更多的移动设备升级到 2.3 Gingerbread 后，也要使用 Firefox 5支持的2.3 Gingerbread 外观。

审核人员必读

审核

• 不要审核自己的修订，除非只是小的改动 (拼写和语法改动或者更新某个图片)。请让另一个审核者来检视你的修订。
• 声明合理的修订级别（对英文原文而言）
  • 小改动，如拼写和语法改动 - 这是第一级也是默认的级别。这种改动一般无需更新相应的翻译，从而也不会推送给翻译人员。
  • 中改动，不需要立即翻译的内容改动 - 这是第二级。这时翻译人员会在控制面板上看到这篇文章需要更新。一般我们使用这一级别来标记可观的内容改动，例如图片的更新，标记的更新，添加删除重要 (但不是核心) 的章节。
  • 大改动，原文内容发生了天翻地覆的变化，从而旧版翻译会过时 - 这是第三级。翻译人员会在控制面板上看到此篇文章需要立即更新，并且一个黄色的警告符号会出现（提示用户优先查看英文原文）。在某篇文章的知识完全过时并被大幅度重写时使用该级别。
• 不要为了取悦某人而批准某一修订 - 你可以与相应的用户在讨论页交流来完善这个修订。管理员会通知新手贡献者来参加讨论。如果你想对某个修订进行一些小改动，你可以使用"基于这个修订版本编辑文章"。
  注意: 这种方法完成的修订会对所有的参与者致谢。我们也可以在需要的时候直接把某人列为对某文章提供了贡献。

送交翻译的文章

将一篇文章标记为"送交翻译"等于告诉翻译人员该文章的英文原文不会出现大的改动，现在就可以着手翻译成其他语言。 这使得翻译人员不会过多地收到无意义的提示。当然，如果希望的话，翻译人员也可以选择英文原文有任何更新的时候收到提示。

具体流程
只有一篇文章的修订级别被标记为2或3，且选中"送交翻译"的选框时，才会出现在翻译人员的控制面板中。该选框只有管理员可以设定。设定后所有订阅了更新提示的用户都会收到电子邮件。

这样做有如下的原因：

• 对具体某个 Firefox 版本对应的文章进行定稿 - 比方说 Firefox 5的某篇文章完成时，我们将其标记为"送交翻译"，再开始针对Firefox 6改动这篇文章。完成Firefox 6的改动后再标记"送交翻译"一次。从翻译人员的角度看，他们先看到这篇文章针对 Firefox 5的版本已经完成并等待翻译，之后（一般是六周后）才收到关于 Firefox 6的翻译提醒。
• 减少提醒的次数，从而避免浪费时间 - 不管我们是把 Firefox 的新功能添加进文章，还是在修改文章，一般要花多次修订才能完善某一个文章的版本。我们可以等到一切都搞定之后再通知翻译人员。
• 测试一篇文章的版本 - 例如我们在对文章进行大改，我们得自己对结果满意后再推送给翻译人员。

添加和删除文章

推荐新文章

我们的知识库为上亿的用户提供帮助信息。每篇文章都相当于在回答用户的问题。但这并不意味着文章越多越好，撰写、翻译和维护都是需要时间精力的。我们的工作重心应该是把现有的文章完善和更新。在决定添加新文章之前，先考虑下面的问题：

这篇文章真的有用吗？
一般来说更新和添加内容到现有文章中去就够了。创建新文章是主要原因有：

• 新功能 - 用户看得到的新功能也会带来新问题。
• 新问题 - 在支持论坛和实时聊天中反复出现的新问题。
• 影响范围广 - 重要的，临时性的大问题需要临时新建文章来解释(例如 Pogo.com和其他的Java页面无法运行)

文章归档

我们会定期归档一些知识库的文章以便专注于更重要的文章。 在六周一版的发布背景下，用户需要的支持信息也会加速演变。诚然，某些经典文章如创建和管理书签 或者 如何设置主页会长期存在，而另一些可能慢慢就过时了。理想的情况下，我们总共需要 175 篇文章，这一方面让我们的知识库足够详细，另一方面维护和翻译的开销也不会太大。

具体流程：
有审核权的贡献者可以编辑文章的简介部分以把一篇文章标记为过时。这会从所有人的控制面板中（包括本地化控制面板）隐藏该文章，也使之无法被普通搜索找到。通过高级搜索，或者其他文章如果链接到这篇文章，还是可以找到它的。只不过文章开头就会注明此文章已过期且不被维护。

归档并不意味着给这篇文章彻底加了封印。我们还是会核实该文章是否真的没有人气了，如果它确实不该标记为过时，只要取消相应的选框，文章就会重见天日。

标记为过时前要考虑的因素：

• 点击率低 - 月点击率低于1500。
• 近期汇报率低 - 近期很少汇报到支持论坛和实时聊天中的问题。
• 影响范围小 - 隐藏该文章不会产生严重问题。
• Firefox 软件已更新 - 随着 Firefox 的bug更新或者软件行为的改变，有些问题将变得过时(还是例如 Pogo.com和其他的Java页面无法运行)。