Mozilla 知识库对所有想做贡献的人开放。任何人都可以提交次要修订来更正或更新我们的支持文章，而无需特殊权限。

本文档描述了通过 Bugzilla 协调的新内容请求和主要更新的工作流程。这些请求遵循不同的流程，因为它们通常需要与产品团队和其他利益相关者协作。

如果您不确定哪种工作流程适用于您的更改，请参阅下面的 经验法则 部分或查阅 文章和更改状态 以了解您提议的更改属于哪个类别。

为什么使用 Bugzilla？

我们使用 Bugzilla 来协调围绕新内容请求和主要更新的讨论，因为这个过程通常涉及多个利益相关者。

使用单一的协作空间有助于确保对话对所有参与者保持透明和可访问。我们特意使用 Bugzilla 而不是知识库文章讨论，因为我们的许多产品利益相关者已经在 Bugzilla 中工作，作为他们正常工作流程的一部分，而相对较少的人熟悉知识库讨论系统。

Bugzilla 还提供明确的任务所有权和进度跟踪。由于内容创建是 Mozilla 员工和社区贡献者之间的协作努力，因此每个人都能轻松看到谁负责请求、做出了什么决定以及还剩下什么工作，这一点非常重要。这有助于避免重复工作，减少混淆，并使与发布相关的文档更容易按计划进行。

经验法则

作为一般规则，您可以问自己以下问题：

此更改是否需要产品团队的输入或验证？

• 如果是，请创建或通过 Bugzilla 工单工作，以便适当的利益相关者可以参与讨论。
• 如果不是，您通常可以直接将更改作为次要知识库更新提交。

换句话-说，如果您提议的更改不需要产品利益相关者的参与，并且属于次要修订的范围，则无需通过 Bugzilla。

为什么存在这个流程

这个流程旨在支持社区贡献。它帮助我们：

• 保护发布时间表
• 明确所有权和责任
• 保持健康的协作
• 避免因期望不明确而引起的摩擦

我们非常重视贡献者的专业知识。社区内长期的产品知识非常有价值。同时，与产品发布和跨职能协作相关的内容工作需要明确的所有权、可预测的时间表和结构化的协调，以便我们能够确保及时交付准确和有用的内容，以支持 Mozilla 的全球用户群。

通过 Bugzilla 处理内容请求的工作流程

以下流程适用于通过 Bugzilla 提交的新内容请求和主要更新。

内容请求通常分为两类：

• 随版本发布请求： 与预定的 Firefox 发布相关的内容。这些请求具有时间敏感性，必须遵循发布时间表。
• 非随版本发布请求： 与预定的 Firefox 发布无关的内容。这些请求可能仍有目标截止日期，但通常允许更大的灵活性。

要获得完整预览，请在新标签页中打开图片。

1. 提交

所有主要内容更新都必须通过 Bugzilla 工单 提交。

2. 分类和分配

分类： 所有新内容请求都会经过分类流程以确定优先级和分配。分类在每周四进行。

对贡献者开放的内容请求将在 Bugzilla 中标记 sumo-contributors 关键字。如果您有兴趣帮助处理其中一个请求，请随时通过直接在 Bugzilla 工单上评论来表达您的兴趣。

分配： 一位 CX 员工将把该 Bug 分配给贡献者或技术撰稿人。一旦分配，社区经理或其他 CX 团队成员将指导您完成整个流程。在 CX 员工确认您的分配之前，请不要开始起草。

时间预期： 分类每周进行一次，贡献者可以在其分配请求后的五个工作日内收到回复。

• 随版本发布请求： 随版本发布请求的分配具有时间敏感性。如果一个与发布相关的请求对贡献者开放，但在下一个分类周期（5个工作日）后仍未分配，CX 团队可能会将其分配给技术撰稿人，以确保发布时间表不被延迟。

• 非随版本发布请求： 非随版本发布请求通常允许更大的灵活性，并且可能会在更长的时间内可供贡献者分配，具体取决于请求的截止日期。

3. 内容创建

内容草稿： 在开始工作前，请仔细审查工单，以了解请求、范围、目标发布或截止日期以及预期结果。

一旦 Bug 分配给您，您就可以开始创建内容。如果产品团队提供了草稿，请以此为起点。否则，您可以在 Google Docs 中开始起草内容。如果无法使用 Google Docs，您可以将草稿直接附加到 Bugzilla 工单中以供审查。

请务必在 Bugzilla 工单中发布您的草稿链接，并设置文档权限以允许利益相关者发表评论。

内容批准： 与请求者或产品利益相关者密切合作，以确保文章完整准确。如果缺少完成工作所需的信息，请使用 Bugzilla 中的“请求信息来源…”选项来收集更多详细信息。

您可以检查 Bugzilla 表单描述的最后一行，看是否已为草稿确定了正式的批准人。

时间预期：

• 随版本发布请求： 应被视为高优先级。除非进度被其他利益相关者的依赖项阻塞，否则如果在分配后一周内或目标发布日前一周内没有准备好有意义的草稿以供审查，CX 团队可能会重新分配随版本发布请求。这有助于确保内容在发布时准备就绪。

• 非随版本发布请求： 草稿通常应在请求的截止日期前至少一周准备好供利益相关者审查。

上报：

• 如果您认为无法满足预期的时间表，请尽快通过更新 Bugzilla 工单或直接联系 CX 员工来通知 CX 团队。及早沟通能让我们有时间调整计划或寻找额外支持，而不会延迟发布。
• 如果您无法从请求者那里获得所需信息，请联系分配该 Bug 的 CX 员工，以帮助您获取所需信息。

4. 内容发布

发布内容： 一旦草稿最终确定并经利益相关者批准，您可以将内容作为实际知识库文章的新修订版提交。

请记住，我们的知识库使用的是自定义 wiki 语法，因此在从 Google Docs 或您用于起草内容的其他工具转移内容时，请确保内容格式正确。

内容审查： 贡献者必须等待其知识库修订版由员工或作者以外的知识库审查员审查。在此阶段，审查主要侧重于质量保证和正确的标记，而不是验证底层产品信息的准确性。

时间预期：

• 随版本发布请求： Bugzilla 工单可能会指定一个与 Firefox 发布时间表一致的计划发布日期。请在目标发布日期前至少两天提交知识库修订版以供审查，除非进度被其他利益相关者的依赖项阻塞。这让审查员有足够的时间完成最终的质量和标记审查，而不会危及发布截止日期。

• 非随版本发布请求： 发布应遵循 Bugzilla 工单中商定的截止日期。

上报： 如果您在审查知识库修订版方面需要帮助，可以通过发送电子邮件至 kb-reviewers@mozilla.com 联系知识库审查员。

工单关闭： 一旦知识库文章发布，可以通过将其标记为“已解决 — 已修复”来关闭 Bugzilla 工单。

理解内容批准与内容审查

历史上，知识库贡献者只熟悉知识库审查流程，任何拥有知识库审查员权限的人都可以审查并批准或拒绝文章修订。

然而，在通过 Bugzilla 工作时，有两个不同的检查点：

1. 内容批准： 在 Bugzilla 的内容创建过程中由相应的产品利益相关者完成。
2. 内容审查： 在文章发布前由知识库审查员完成。

尽管两者都很重要，但它们的目的不同。

利益相关者的内容批准

“内容批准”的主要目标是与产品利益相关者验证内容的实质和意图。这包括确保内容草稿：

• 技术上准确，并反映预期的产品行为
• 与批准的产品术语和命名惯例保持一致
• 与 Mozilla 的品牌声音和信息传递保持一致

知识库审查员的内容审查

“内容审查”通过关注文章的质量和呈现方式来补充批准。在此阶段，知识库审查员验证文章：

• 使用正确的语法和格式，包括wiki 标记
• 清晰、结构良好且易于理解
• 遵循 Mozilla 的编辑和内容指南

总之，这两个步骤有助于确保每篇文章在发布前既技术准确又易于用户理解。

贡献者附加指南

• 分配公平性

与产品团队有直接关系的贡献者可能会在请求正式提交之前就意识到即将到来的请求。但是，请不要在内容请求创建和分类之前开始工作或请求分配。这确保了所有贡献者都有开放和平等的贡献机会。

• 尊重分类流程

请给予 CX 团队完整的 5 个工作日分类窗口来审查和分配 Bugzilla 工单。在此期间结束前，请避免请求或施压以获取分配决定。

• 沟通可用性变更

我们理解可能会出现意外情况。如果您无法满足您承诺的截止日期，请尽快通知 CX 团队，以便我们相应地进行调整。

• Bugzilla 工单重开政策

请不要重新打开已解决的 Bugzilla 内容请求工单，以请求审查与原始请求不直接相关的修订。对于相关更新，请在现有工单中添加新评论，而不是重新打开它。如果您没有评论权限，请将您的请求上报至 kb-reviewers 邮件列表（见下文）。

不符合此标准而重新打开工单可能会导致请求被驳回。请遵循 Bugzilla 礼仪 以维持富有成效和相互尊重的协作。

• 加急审查请求

如果新文章或修订需要更快的周转时间，例如紧急产品变更、持续性事件或严重不准确之处，您可以发送电子邮件至 kb-reviewers@mozilla.com 请求加急审查。

查找可参与的内容请求

我们鼓励贡献者通过 Bugzilla 参与内容请求，只要它们符合下一节中描述的标准。以下是您可以查找传入内容请求的方法：

• 手动监控

您可以通过检查未分配的内容请求列表来关注新的内容请求。如果您发现想要处理的请求，只需在 Bug 上留言，让 CX 团队知道您有兴趣。

分类后，对社区贡献开放的内容请求将在 Bugzilla 中标记为 sumo-contributors 关键字。您可以使用此关键字来跟踪正在进行的请求，这些请求可供贡献者使用。

• 保持更新

如果您想收到有关新内容请求的通知，可以考虑在 Bugzilla 上关注知识库内容组件。为此，请转到您的 Bugzilla 个人资料 → Edit Profile & Preferences → Component Watching。在产品选择中选择 support.mozilla.org，在 Component 字段中选择 Knowledge Base Content，然后单击 Add 按钮以保存您的更改。

分配标准

如果内容请求满足以下条件，可以将其分配给贡献者：

• 不包含机密信息

涉及禁运信息或敏感内容的内容请求将由员工负责。

• 不涉及紧密的内部依赖

涉及信息敏感性、合规性审查或不断演变的规范并需要与法律、市场营销和传播、安全以及外部合作伙伴积极协调的请求，也将由员工负责。

• 与付费产品无关

与订阅产品和付费功能相关的内容请求必须由员工负责，因为涉及法律、合规、测试和跨职能协调的要求。这些请求通常涉及合同、计费或与发布相关的敏感信息，需要集中问责。

• 非时间敏感

周转时间少于 5 天的内容请求将由员工负责，以确保及时交付并与发布时间表保持一致。

• 贡献者能力

贡献者一次最多只能有3 个活动分配。这有助于确保专注执行并防止工作量失衡。我们认识到，由于技术依赖性，某些请求可能会被延迟。如果一个请求因产品端依赖而被阻塞超过两周，该工单可能被视为不活跃（陈旧），并从贡献者的工作量预期中排除。

附加说明：

• 这仅适用于通过 Bugzilla 提出的请求，不适用于次要的知识库修订。
• 这不适用于常用论坛回复的创建。
• 员工对已发布的内容负有最终责任。