ms.openlocfilehash | ms.sourcegitcommit | ms.translationtype | ms.contentlocale | ms.lasthandoff | ms.locfileid |
---|---|---|---|---|---|
33178637c4fcfb21e8190c3d2593f09326ea5995 |
7588136e355e10cbc2582f389c90c127363c02a5 |
HT |
zh-CN |
03/14/2020 |
73166634 |
处理的目标是:
- 确保文档中的错误或遗漏不会阻碍客户的正确操作。
- 对客户的反馈和关注作出回应。
- 不断改善客户体验。
- 通过关于挑战和解决方案的开放式对话,了解有关客户体验的更多信息。
处理采用两个阶段,在确定工作优先级的同时确保响应能力。 初始阶段诊断并会审问题。 第二个阶段解决问题。 如果问题简单但紧急,这两个阶段可能会合二为一。
处理涉及具有固定时间分配的任务:
每个团队成员每个工作日最多花费 30 分钟时间对新问题进行分类。 我们会回答以下问题:
- 是文档问题还是产品问题?
- 这不是一个问题,而是一个更适合论坛或支持站点的问题吗?
- 问题的优先级是什么?
- 哪个区域负责管理此问题?
如果在初始检查中无法解答这些问题,我们会要求在注释中阐明问题。
在诊断和会审阶段会关闭以下类型的问题:
- Kudos:我们表示感谢,并关闭问题。
- 产品问题:关闭与产品相关但不与其文档相关的问题。 我们还可以执行如下所述的其他操作。
- CoC 冲突:如果 CoC 冲突值得报告和阻止,则会关闭并报告这些问题。
- 重复项:关闭注释中引用现有问题的重复项。
- doc-ok:客户不正确,文档正确。
- 论坛:支持的问题或论坛请求会定向到 Stack Overflow 或其他支持站点,然后关闭这些问题或请求。
根据产品问题的性质,我们可以选择:
- 将问题转移到相应的产品存储库。
- 将问题作为现有产品请求的重复项关闭。
- 关闭问题,并建议在产品存储库上打开。
对正确操作过程的评估是主观的。 团队成员根据自己的判断来进行正确的操作。
对于其他问题,团队:
- 分配优先级
- 分配里程碑,通常为“积压工作 (backlog)”
- 评估问题是否是“容易作答”的恰当问题,或适用于 .NET 社区参与者的项目
优先级别基于以下准则,但具有主观性。 里程碑也是主观的,并基于其他优先级,如当前产品发布计划和即将推出的产品。
- P0:文档遗漏或错误会阻碍客户在常见方案中正常操作。
- P0 问题会在接下来的三周内进行处理,优先于以前计划的工作。
- P1:文档遗漏或错误会使常见方案更加难以实现,或者阻碍其他已知方案。
- P1 问题将会及时安排处理。 通常情况下,会针对即将到来的里程碑计划 P1 问题。
- P2:导致轻微不便或略微影响文章页面视图的问题。
- 出于优先级较高的原因更新文章时,通常会修复 P2问题。
- P3:针对边缘案例方案请求的问题。
- P3 问题会置于积压工作 (backlog) 中,并在出于优先级较高的原因更新文章时才考虑更新。
团队成员在诊断和会审方面花费的时间有限,这样他们可以有更多时间推进计划的任务。 每个团队成员每天最多花费 30 分钟进行诊断和会审。
当某个问题适合社区成员(可能为作者)提交修复时,将应用“容易作答” 标签。 应用“容易作答” 标签的团队成员将帮助或请某人帮助社区成员完成 PR 创建过程。 “容易作答”的问题通常会添加到社区贡献项目
注意:我们仅在最近采用了上述约定。 添加标签的人员可能会将你推荐给为你提供帮助的其他团队成员。
客户生成的问题将作为安排任务计划的一部分来衡量。 每个团队成员每周分配 4 小时来解决最高优先级的客户问题。
问题解决遵从诊断过程中设置的优先级别。 传入的客户问题优先于其他类似优先级的计划工作
- P0:只要是合理的,就会在接下来的三周内解决。
- P1:与其他计划的 P1 工作一起安排。 这通常意味着在接下来的三个月内解决。
- P2:与其他计划的 P2 工作一起安排。 基于区域和可见性定期安排 P2 问题。 文章更新时,通常会解决 P2 问题。
- P3:不保证修复日期。 更新文章时,我们会检查同一文章中其他问题的积压工作 (backlog)。
可能会根据新的反馈和文章可见性数据重新确定问题的优先级。