VSCode的问题疏导方法

我们的GitHub社区是我们成功的最大原因之一。每天，您都会提出50-250个问题，提出鼓舞人心的新功能创意，告诉我们哪些功能能达到预期效果，哪些不能，还能告诉我们如何改进现有的功能。我们非常感谢您创造的每一个问题。谢谢!。

尽管我们尽了最大努力处理所有这些问题，但随着时间的推移，我们落在了后面。当您查看问题时，有时不清楚我们是否打算提供您建议的功能，是否修复错误，问题是否与另一个问题重复。

为了恢复合理的清晰度，我们每年都会进行一次内务迭代，在这个迭代中，我们会检查所有未解决的问题。我们对问题进行分类、标记、修复和结案。这导致了一波通知的浪潮，这很难处理(我们的道歉)，但最终会更好地理解你的想法会发生什么。

我们在机器人的帮助下关闭问题，该机器人响应特定的评论，如#1234的/Duplicate of#1234，或者通过向问题添加预装的评论并关闭问题来分配标签。

功能请求就像所有问题一样，是我们与社区之间以及社区成员之间沟通的一种方式。因此，原则上，我们可以使所有功能请求保持打开状态，而不管它们所描述的功能会发生什么情况。但是，这使得您很难理解什么是真正有机会进入存储库的。因此，我们关闭了我们不会解决的功能请求。

如果您是功能请求的作者，您可能不喜欢我们关闭您的问题。它甚至可能感觉像是在你脸上打了一记耳光。我们明白这一点。我们所有人也都在那里-在这个项目中或我们为之做出贡献的其他项目中。所以，请放心，我们喜欢您的所有意见。当我们决定结束您的问题时，请不要冒犯您。如果您觉得您的功能请求应该保持开放，请改进您的用例或收集更多向上投票。然后ping我们，我们将考虑重新打开功能请求。

以下是我们用来决定是否关闭功能请求的标准：

功能请求中描述的功能是否有任何合理的机会在未来24个月内实施？24个月比我们概述未来6-12个月的路线图要长。因此，我们有一些水晶球的读数，我们很可能会保持更多的功能请求，而不是我们在24个月内可以完成的。

整个社区是否对此功能表示了兴趣？也就是说，它收集了10多张赞成票或10多条评论吗？截至2019年10月9日，仅这一标准就涵盖了2850个开放功能请求中的650多个。

我们是否认为这项功能请求是大胆和前瞻性的？我们是否希望看到它在某个时候得到解决，即使它还需要超过24个月的时间？(显然，这是最主观的标准。)。

如果三个问题中的任何一个的答案是肯定的，那么我们就会问负担能力：

我们的团队是否负担得起实现该功能的费用？也就是说，与我们团队的规模相比，实现功能的成本是否合理？

总而言之，一个功能需要通过1-3和4中的一个。否则，我们会将其关闭，因为它超出了范围。我们将取消订阅这些问题，以减少我们每天收到的问题通知总数。

如果存在负的成本效益平衡，我们就会关闭错误，因为这是无法修复的。这并不是说我们不关心受问题影响的用户，而是，例如，如果修复非常复杂，以至于尽管我们进行了所有测试，许多用户仍有倒退的风险，修复就不是一个合理的选择。当我们在无法修复的情况下关闭错误时，我们会说明我们这样做的原因。

我们给一些问题贴上了上游的标签。上游意味着问题在我们使用的包或库中，我们不能独立修复。如果我们可以在存储库中的问题和包或库的问题跟踪器中的问题之间建立清晰的可追溯性链接，我们就关闭了上游问题。在某些情况下，这是不可能的，例如，我们可能已经确定一个问题是Chromium问题，但是Chromium还不接受这个问题，因为再现案例太复杂了。

每个问题都必须有一个类型标签。大多数类型的标签是灰色的，有些是黄色的。虫子是灰色的，略带红色。

如果问题适合初学者，我们可以添加Good-First-Issue标签，并添加代码指针来帮助初学者开始使用公关。

我们将计划在整理期间修复的bug分配给当前迭代的里程碑。