Bug 分类和问题管理#

问题跟踪器

在项目中的沟通中非常重要：它帮助开发者识别主要的工作项目，以及讨论优先级。因此，对问题进行管理，添加标签并关闭不必要的问题是很重要的。

改进问题以提高解决的可能性#

改进问题可以增加其成功解决的机会。提交优质问题的指南可以在这里找到。第三方可以提供有用的反馈，甚至可以在问题上添加评论。以下行动通常是有用的：

记录缺少重现问题所需元素的问题，例如代码示例
建议更好地使用代码格式
建议重新表述标题和描述，使其更明确地说明要解决的问题
在简要描述它们如何相关的同时，链接到相关问题或讨论，例如“另见 #xyz 对此的类似尝试”或“另见 #xyz 在 SomeEstimator 中发生了同样的事情”提供了上下文并有助于讨论。

协助审查 PR#

审查代码也是鼓励的。贡献者和用户欢迎根据我们的审查指南参与审查过程。核心团队和贡献者体验团队成员的分类操作 —————————————-

除了上述内容，核心团队和贡献者体验团队的成员可以执行以下重要任务：

更新问题和PR的标签：查看可用的GitHub标签列表。
确定PR是否必须重新标记为停滞或需要帮助（这在冲刺期间通常非常重要，因为风险是创建许多未完成的PR）
如果一个停滞的PR被一个新的PR接管，那么将停滞的PR标记为“被取代”，在停滞的PR上留下评论并链接到新的PR，并可能关闭停滞的PR。
分类问题：
- 关闭使用问题 并礼貌地引导报告者改用Stack Overflow。
- 关闭重复问题，在确认它们确实是重复的之后。理想情况下，原始提交者将讨论转移到较旧的重复问题上
- 关闭无法复现的问题，在留出时间（至少一周）以添加额外信息之后

保存的回复在分类时有助于节省时间，同时保持友好和礼貌。

查看GitHub关于组织中的角色描述。

分类问题的典型工作流程#

以下工作流程 [1] 是处理问题分类的一个好方法：

感谢报告者提出问题

问题跟踪器是许多人与 scikit-learn 项目互动的第一步，而不仅仅是使用库。因此，我们希望这是一个热情、愉快的体验。
这是一个使用问题吗？如果是，请礼貌地关闭它并附上示例信息（示例在此）。
是否提供了必要的信息？

如果缺少关键信息（如使用的 scikit-learn 版本），请随时要求提供这些信息，并将问题标记为“需要信息”。
这是一个重复的问题吗？

我们有许多开放的问题。如果新问题似乎是重复的，请指向原始问题。如果是明显的重复，或者共识认为它是多余的，请关闭它。确保仍然感谢报告者，并鼓励他们在原始问题上发表意见，甚至尝试修复它。

如果新问题提供了相关信息，例如更好或略有不同的示例，请将其作为评论添加到原始问题中，或编辑原始帖子。
确保标题准确反映问题。如果你有必要的权限，如果不清楚，请自行编辑。
问题是否最小且可重现？

对于错误报告，我们要求报告者提供一个最小可重现的示例。参见 Matthew Rocklin 的这篇有用的帖子 <https://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports> `_ 以获得很好的解释。如果示例不可重现，或者显然不是最小的，请随时要求报告者提供示例或简化提供的示例。请承认编写最小可重现的示例是艰巨的工作。如果报告者遇到困难，你可以尝试自己编写一个。

如果提供了可重现的示例，但你觉得可以简化，请添加你的更简单的可重现示例。
添加相关标签，例如当问题是关于文档时添加“Documentation”标签，如果是明显的错误则添加“Bug”标签，如果是增强请求则添加“Enhancement”标签，…

如果问题定义明确且修复似乎相对简单，请将问题标记为“Good first issue”。

另一个有用的步骤是，在相关时标记相应的模块，例如` sklearn.linear_models ` 。
如果标签存在，请从问题中移除“Needs Triage”标签。