Bug triaging and issue curation#
issue tracker对于项目的沟通非常重要：它帮助开发者确定要开展的主要项目，并讨论优先级。因此，对其进行整理至关重要，包括为议题添加标签以及关闭不必要的议题。
致力于改进议题#
改进议题可以增加它们成功解决的机会。有关提交高质量议题的指南可在此处找到。第三方可以提供有用的反馈，甚至在议题上添加评论。以下行动通常很有用：
记录缺少重现问题所需元素（如代码示例）的议题
建议更好地使用代码格式化
建议重新 формуulate 标题和描述，使其更明确地说明要解决的问题
链接到相关议题或讨论，并简要描述它们之间的关系，例如“另请参阅 #xyz，了解类似尝试”或“另请参阅 #xyz，其中在 SomeEstimator 中发生了相同的事情”，这提供了背景信息并有助于讨论。
致力于 PR 以帮助审查#
也鼓励审查代码。贡献者和用户欢迎按照我们的审查指南参与审查过程。
核心和贡献者体验团队成员的分类操作#
除了上述内容外，核心团队和贡献者体验团队的成员还可以执行以下重要任务：
更新议题和 PR 的标签：查看可用的 github 标签列表。
确定 PR 是否必须重新标记为 stalled 或需要帮助（这在冲刺中通常非常重要，因为存在创建许多未完成 PR 的风险）
如果一个停滞的 PR 被一个新的 PR 接替，则将停滞的 PR 标记为“Superseded”，在停滞的 PR 上留下评论链接到新的 PR，并可能关闭停滞的 PR。
分类议题
关闭使用问题，并礼貌地指出报告者改用 Stack Overflow。
关闭重复议题，在检查它们确实重复之后。理想情况下，原始提交者将讨论转移到较旧的重复议题中。
关闭无法重现的议题，在留出时间（至少一周）添加额外信息之后。
保存的回复在分类时很有用，可以节省时间，同时保持热情和礼貌。
请参阅 github 对组织中角色的描述。
分类议题的典型工作流程#
以下工作流程[1]是处理议题分类的好方法
感谢报告者提出议题
议题跟踪器是许多人与 scikit-learn 项目本身（不仅仅是使用库）的第一次互动。因此，我们希望它成为一个热情、愉快的体验。
这是使用问题吗？如果是，请用礼貌的消息关闭它（此处有一个示例）。
是否提供了必要的信息？
如果缺少关键信息（例如使用的 scikit-learn 版本），请随时要求提供，并用“Needs info”标记议题。
这是重复议题吗？
我们有许多未解决的议题。如果一个新议题看起来是重复的，请指向原始议题。如果它是一个明显的重复，或者共识认为它是多余的，请关闭它。请务必仍然感谢报告者，并鼓励他们在原始议题上发表意见，并可能尝试修复它。
如果新议题提供了相关信息，例如更好或略有不同的示例，请将其作为评论或对原始帖子的编辑添加到原始议题中。
确保标题准确反映议题。如果您有必要的权限，如果标题不清楚，请自行编辑。
议题是否最小且可重现？
对于错误报告，我们要求报告者提供一个最小的可重现示例。有关良好解释，请参阅 Matthew Rocklin 的这篇有用文章。如果示例不可重现，或者它显然不是最小的，请随时询问报告者是否可以提供示例或简化提供的示例。请承认编写最小可重现示例是很困难的工作。如果报告者遇到困难，您可以尝试自己编写一个。
如果提供了可重现示例，但您看到了简化方法，请添加您更简单的可重现示例。
添加相关标签，例如当议题是关于文档时为“Documentation”，如果它显然是错误则为“Bug”，如果是增强请求则为“Enhancement”，等等。
如果议题定义明确且修复看起来相对简单，请将议题标记为“Good first issue”。
另一个有用的步骤是标记相应的模块，例如在相关时标记
sklearn.linear_models。如果标签存在，请从议题中删除“Needs Triage”标签。