Skip to content

Latest commit

 

History

History
91 lines (63 loc) · 5.28 KB

issues-policy.md

File metadata and controls

91 lines (63 loc) · 5.28 KB
ms.openlocfilehash ms.sourcegitcommit ms.translationtype ms.contentlocale ms.lasthandoff ms.locfileid
33178637c4fcfb21e8190c3d2593f09326ea5995
7588136e355e10cbc2582f389c90c127363c02a5
HT
zh-CN
03/14/2020
73166634

GitHub 问题处理和策略

处理的目标是:

  1. 确保文档中的错误或遗漏不会阻碍客户的正确操作。
  2. 对客户的反馈和关注作出回应。
  3. 不断改善客户体验。
  4. 通过关于挑战和解决方案的开放式对话,了解有关客户体验的更多信息。

处理采用两个阶段,在确定工作优先级的同时确保响应能力。 初始阶段诊断并会审问题。 第二个阶段解决问题。 如果问题简单但紧急,这两个阶段可能会合二为一。

处理涉及具有固定时间分配的任务:

  • 每个团队成员每个工作日最多花费半小时将传入问题进行分类(包括对初始响应分类)。 这可确保我们能够及时响应新问题。
  • 每个团队成员每周最多花费半天时间来更新文档,以解决客户生成的 GitHub 问题。

诊断阶段

每个团队成员每个工作日最多花费 30 分钟时间对新问题进行分类。 我们会回答以下问题:

  • 是文档问题还是产品问题?
  • 这不是一个问题,而是一个更适合论坛或支持站点的问题吗?
  • 问题的优先级是什么?
  • 哪个区域负责管理此问题?

如果在初始检查中无法解答这些问题,我们会要求在注释中阐明问题。

在诊断和会审阶段会关闭以下类型的问题:

  • Kudos:我们表示感谢,并关闭问题。
  • 产品问题:关闭与产品相关但不与其文档相关的问题。 我们还可以执行如下所述的其他操作。
  • CoC 冲突:如果 CoC 冲突值得报告和阻止,则会关闭并报告这些问题。
  • 重复项:关闭注释中引用现有问题的重复项。
  • doc-ok:客户不正确,文档正确。
  • 论坛:支持的问题或论坛请求会定向到 Stack Overflow 或其他支持站点,然后关闭这些问题或请求。

针对产品问题的操作

根据产品问题的性质,我们可以选择:

  • 将问题转移到相应的产品存储库。
  • 将问题作为现有产品请求的重复项关闭。
  • 关闭问题,并建议在产品存储库上打开。

对正确操作过程的评估是主观的。 团队成员根据自己的判断来进行正确的操作。

针对内容问题的操作

对于其他问题,团队:

优先级别基于以下准则,但具有主观性。 里程碑也是主观的,并基于其他优先级,如当前产品发布计划和即将推出的产品。

  • P0:文档遗漏或错误会阻碍客户在常见方案中正常操作。
  • P0 问题会在接下来的三周内进行处理,优先于以前计划的工作。
  • P1:文档遗漏或错误会使常见方案更加难以实现,或者阻碍其他已知方案。
  • P1 问题将会及时安排处理。 通常情况下,会针对即将到来的里程碑计划 P1 问题。
  • P2:导致轻微不便或略微影响文章页面视图的问题。
  • 出于优先级较高的原因更新文章时,通常会修复 P2问题。
  • P3:针对边缘案例方案请求的问题。
  • P3 问题会置于积压工作 (backlog) 中,并在出于优先级较高的原因更新文章时才考虑更新。

团队成员在诊断和会审方面花费的时间有限,这样他们可以有更多时间推进计划的任务。 每个团队成员每天最多花费 30 分钟进行诊断和会审。

当某个问题适合社区成员(可能为作者)提交修复时,将应用“容易作答” 标签。 应用“容易作答” 标签的团队成员将帮助或请某人帮助社区成员完成 PR 创建过程。 “容易作答”的问题通常会添加到社区贡献项目

注意:我们仅在最近采用了上述约定。 添加标签的人员可能会将你推荐给为你提供帮助的其他团队成员。

解决阶段

客户生成的问题将作为安排任务计划的一部分来衡量。 每个团队成员每周分配 4 小时来解决最高优先级的客户问题。

问题解决遵从诊断过程中设置的优先级别。 传入的客户问题优先于其他类似优先级的计划工作

  • P0:只要是合理的,就会在接下来的三周内解决。
  • P1:与其他计划的 P1 工作一起安排。 这通常意味着在接下来的三个月内解决。
  • P2:与其他计划的 P2 工作一起安排。 基于区域和可见性定期安排 P2 问题。 文章更新时,通常会解决 P2 问题。
  • P3:不保证修复日期。 更新文章时,我们会检查同一文章中其他问题的积压工作 (backlog)。

可能会根据新的反馈和文章可见性数据重新确定问题的优先级。