如果您使用 R，您可能想知道是否有方法可以帮助改进 R。这是关于如何提供帮助的几篇博文中的第一篇。这篇文章是关于帮助审查和解决在 R 错误跟踪器 上报告的错误。
紧急错误报告，尤其是那些具有简单可复现示例的报告，通常会得到快速解决和关闭。但那些没有得到解决的报告有时可能会长期搁置。在撰写本文时，错误跟踪器中有 579 个未解决的错误报告。有些反映了已经解决或不再适用的问题，有些可能是有效的，但由于复杂性或缺乏可复现的示例而难以追踪。其他错误反映了对已记录行为的误解，理想情况下应该将这些误解传达给报告者。
为了让我们能够将更多资源集中在改进 R 上，并使错误报告过程更具响应性，我们可以借助您的帮助来审查和处理报告的错误。如果您愿意提供帮助，以下是一些您可以做的事情
如果您还没有 Bugzilla 帐户，请发送一封电子邮件（从您希望用作登录名的地址）到 [email protected]，简要说明原因，一位志愿者会将您添加到 R 的 Bugzilla 成员中。
查看一些较旧的报告，并找出由于其他原因已经解决或不再适用的报告，并在报告中添加一条评论来解释原因，以便具有必要权限的 Bugzilla 成员可以将其关闭。
找出错误报告反映了对已记录行为的误解的情况，写一条评论向报告者解释这一点，并建议可以关闭该错误。
有时，这样的报告可能会建议更改已记录的行为。由于我们对向后兼容性的坚定承诺，这通常很困难，但有时是可能的。打开“愿望清单”项（在 报告错误链接 中记录）可能是一个好主意。
查找一些缺少可重复示例或示例过于复杂的报告。R FAQ 和 R 主页 上的 报告错误链接 提供了一些有关创建良好错误报告的建议。
在此过程中，您可能会发现没有错误，可以关闭报告。您还可能会发现存在错误，但错误在贡献的包中。也可以关闭此错误，最好在通知维护人员后关闭。
如果事实证明 R 中存在错误，那么解决错误的关键是生成一个简单的可重复示例，该示例可以清楚地识别错误。通常可以使用 R 代码来完成此操作，在极少数情况下，需要查看此 R 代码将执行的内部 C 代码。这通常是追踪错误最耗时的过程，也是我们最需要您帮助的地方。一旦明确隔离错误，实际修复错误通常很简单，因此您不必觉得自己需要想出一个补丁。但以这种方式缩小错误范围将非常有帮助。
对于某些错误，您可能需要一些 C 编程知识才能准确识别问题，但对于大多数错误，您只需要在 R 级别上工作即可。
通过帮助完成这些事情，您将通过使 R 更可靠并释放 R 核心开发人员的时间来专注于更多新开发和改进，从而为 R 做出贡献。您还将提高自己的 R 技能并更多地了解 R 的工作原理。