如何处理GitHub中的遗弃问题？

如果有人在GitHub上发布问题，但询问并且从未给出更多信息来重现该错误，则正常程序是什么？实例。

作者在这里指出“导航中断”。虽然我相信它是固定的，但我希望作者能确保我们正在谈论同一件事。但有时候，问题的记者就消失了。为遗留的问题设置到期日期是一种好/常见的做法吗？

类似于以下情况：

• 对此问题提出了一个问题，以便能够对其进行调试。
• 自开发团队上一次未回答的问题/评论以来，已经过去了2到6个月。
• 错误在关闭时无法复制（出于任何原因，也许永远都无法复制）。
• 关闭警告前2周会发出警告。

项目通常做什么？我在Google上找不到任何东西。另外，我将如何记录呢？README.md中的简单注释是否详细说明了上述要点，并在问题中提供注释以说明为什么将其关闭就足够了？

注意：与该问题有所不同，因为该错误可能仍然是相关的（或无关），但是缺少信息。

这是一个难题：您不能以“已解决”的方式解决该问题，因为您实际上不知道该问题是否已解决，或者至少即使某个问题已解决，您实际上也不知道这是否是报告者的问题在谈论。另一方面，您不想留下可能已经解决的问题，尤其是如果您永远无法得到确认而无法将其关闭时，尤其如此。

因此，您应该将其关闭，但可能不应该 “固定”关闭。如果您想成为肯定的，则可以提出自定义关闭原因“ maybefixed”或“ unconfirmedfix”，如果不想，则可以创建“ reportervanished”。您也可以只说“无法复制”，然后等待弹出相同的错误以寻找响应速度更快的报告器。

但是，您不应将资源花费在一个永远不会知道该错误是否已修复的错误上。

您的主要问题已经回答，但您还询问有关记录过程的信息，也需要回答。

我在许多项目中看到的解决方案不是将其放在项目的README.md中，而是在特殊的自述文件README中 -供参与者使用的README文件。该文件描述了您希望项目参与人员知道的所有信息-有关代码（命名约定，模块组织等）或有关过程（如何编写提交，如何处理故障单等）的信息。该文件可以是.MD项目中的另一个文件，也可以放置在完全不同的存储库中（因此可以在所有项目中共享）。只是不要忘记从主要链接到它README.md！

从主自述文件中分离出该信息的目的是，通常只有项目用户的一小部分直接对其进行贡献。大多数用户不需要无聊的信息-他们只需要知道您的项目做什么以及如何使用它，而这正是自述文件的主要内容。在您的项目中，贡献部分非常小，因此不会妨碍主要的自述文件-但是，如果您记录了所有要贡献者遵循的工作流程，那么它将不再适合在那里...

请注意，任何用户都可以打开错误，因此，如果您对打开错误有特殊要求，则应将其放在主自述文件中（尽管尽量使其紧凑-与代码提供者不同，错误报告者可能不太愿意花很多时间写学习并遵守您的规则）。但是，实际修复错误并关闭故障单的人（无论是您还是您已确认的贡献者之一）是直接的贡献者，可以预期阅读该贡献自述文件-因此，当举报人这样做时，关闭故障单的过程没有回应应在此处进行说明。

我读这更多的是关于如何处理未验证的错误（使用github的问题跟踪器）的实践问题，而不是其他任何问题。

对我来说，基于我使用的其他问题跟踪器，这是一个相当简单的答案。Github不会强迫任何人使用任何工作流程，这使其变得非常灵活……并且在其默认配置中毫无用处。

查看Bugzilla的默认工作流程，我们得到：

我要指出一个非常重要的事情- 在经过验证后，它会按固定方式解决，然后关闭。Github基本工作流程仅显示红色（打开）和绿色（关闭）状态。

因此，一种方法是使用Github中的标签（您的应用程序的标签）来尝试显示其他信息。您可以创建一对“未验证”和“已验证”的标签，以在解决问题后立即应用。请注意，这只是一种方法-如果您进行搜索，则会发现数十种使用标签的不同方法。在这里，问题如何为（优先级等）管理github问题？解决这个问题。

从开发人员的角度来看，您已经解决了问题。在Github上关闭问题。在其上贴上“未验证”标签。一旦熟悉先前版本中的错误的人说“是的，此问题已解决”，您可以将标签更改为“已验证”。如果他们说没有，那么您重新打开它。

还请注意，除了“固定”状态外，还有其他解决状态。有“ wontfix”（修复程序无法使用当前结构完成），“ worksforme”（无法复制该错误）和“ invalid”（您正在提交有关操作系统的错误，不是应用类型的东西）。

我将采用以下两种观点中的一种，具体取决于我对与原始记者谈论同一件事的信心：

1）由于无法再使用该报告程序，因此请认为所涉及的错误意味着您已修复的错误。如果有帮助，请附加测试用例以明确发现的故障。在错误报告中详细描述您所修复的问题，并留下类似“我相信这就是'nav breaks'的意思，如果不是您想要的意思，请重新打开或引发一个新的错误”之类的注释。将错误标记为已修复。

2）由于报告者不再可用，因此认为该错误无法（已知）被复制，因为只有报告者的话才能确认该错误与他们报告的相同。举一个新的bug来描述您所修复的问题，为便于提及，请在缺席的记者描述的情况下观察到该错误，并注意它们可能是重复的，将新的bug标记为已修复并将此错误标记为无效或无法复制，例如“我无法弄清'nav breaks'的意思，但我已经解决了我确实发现的问题。如果nav仍然损坏，请重新打开或引发新的错误，请在更详细地说明出了什么问题”。

至于时间表，我认为这应该取决于项目。如果您的响应速度非常快，并且在出现此错误后的几天内就对其进行了处理，那么人们应该理解，在解决问题之前，您不会等待几周的响应。另一方面，如果它在您的草堆上放置了几个月，则可以再打开一两个月而不会给您造成任何麻烦。

因此，我认为没有一个特定的时限可以构成“良好实践”，也不需要您发布政策并坚持下去。当然，您不希望记录在您努力与记者联系之前无法与之联系的情况。但是我也看不出有什么要紧要关头的警告，直到最后期限：他们会重新访问该错误并想说些什么，或者他们不会。