新的反馈系统即将推出 docs.microsoft.com

这篇文章是由 docs.microsoft.com 团队高级项目经理罗布·艾森伯格 撰写的。

Microsoft的使命是授权地球上的每一个人和每个组织实现更多目标。 这是我们 在开放 GitHub 平台的基础上构建 docs.microsoft.com 的注意事项之一。 今天，我们将将其提升到下一级，并迁移到基于 GitHub 的新文档反馈系统。

GitHub 上的内容反馈

虽然我们的文档自一开始就在 GitHub 上，但我们的内容反馈机制一直在使用 Livefyre 来评论文章。 虽然 Livefyre 是一个很好的评论解决方案，但它事实证明不足以满足我们的特定需求，即跟踪、分配所有者和维护客户提出的内容问题的状态。

我们探索了一些途径来改善它，但一个指导我们大部分工作的问题似乎重新浮出水面：如果我们的文档被当作开源代码对待，我们将使用什么来解决这个问题？ 问题答案似乎很明显：GitHub 问题，因此我们开始更深入地尝试将 GitHub API 集成到我们的文档页面中，从而能够在 GitHub 基础结构的基础上构建完整的反馈系统。

使用新系统，现在可以直接从内容页创建 GitHub 问题，这样就可以以更丰富的方式与编写者和产品团队进行交互。 查看文档的问题？ 错误的代码示例？ 令人困惑的解释？ 一个关键的遗漏？ 只需滚动到页面底部并选择 提供文档反馈。

可以直接从文档页面本身查看与文档关联的所有打开和关闭问题 -这样，在解决问题并解决问题时，始终了解问题：

你可以评论甚至 添加对你很重要的问题 的反应：

现在，Microsoft员工可以利用 GitHub 问题的全部功能对报告的问题进行会审、响应、计划和修复-并且你始终能够了解该过程！

示例文档反馈

假设你在文章中提交 GitHub 问题，以获取中断的超链接。 我们的团队将对问题进行会审，分配标签，并分配所有者进行修复（或提出后续问题）。 当所有者提交修复问题的拉取请求时，你将收到通知（基于 GitHub 通知设置），该问题已解决/关闭，从而创建一个良性的反馈循环。

此外，还可以利用所有标准的 GitHub 良好性，例如注释中的 Markdown、单个问题的订阅或整个存储库、组织活动的 RSS 源、@ 提及、被分配者等！ 我们相信，更深入的开源工具集成将促进社区增长和协作的新机会。

产品反馈分离

上一个系统的问题之一是产品与文档反馈之间的混合在一个流中 - 当并非所有项目都一致标记时，很难对项目进行会审和跟进。 我们向前迈出了一步，通过创建一个明确的方法来分离这两个问题来解决此问题：

通过单击“提供产品反馈，你现在将直接转到与特定文档页面关联的产品团队处理产品反馈的网站。

Roll-Out

你可能想知道反馈系统何时推出。 我们已在 Visual Studio IDE 和 Azure CLI 文档试运行了几个月。 从 2 月中旬开始，我们将开始在所有 docs.microsoft.com 中推出此功能。

反馈

你的反馈对我们很重要，因此我们希望快速掌握这一新系统。 虽然这是我们改进平台上的反馈和参与的下一步，但绝不是我们最后一步。 请务必在 GitHub 上表达你对更改的看法，或在 Twitter 上标记我们。