错误分类和发布策展#

的 issue tracker 对于项目中的沟通很重要：它帮助开发人员确定要工作的主要项目，以及讨论优先级。出于这个原因，重要的是要策划它，为问题添加标签并关闭不必要的问题。

致力于解决问题以改善它们#

改善问题会增加成功解决的机会。可以找到提交好问题的指南 here .第三方可以提供有用的反馈，甚至添加有关问题的评论。以下操作通常很有用：

记录缺少元素以重现问题的问题，例如代码样本
建议更好地使用代码格式
建议重新制定标题和描述，使其更加明确需要解决的问题
链接到相关问题或讨论，同时简要描述它们的相关性，例如“另请参阅#xyz了解对此的类似尝试”或“另请参阅#xyz，其中在SomeEstimate中发生了同样的事情”提供了背景并有助于讨论。

致力于PR以帮助审查#

还鼓励审查代码。欢迎贡献者和用户参与我们的审查过程 review guidelines .

核心和贡献者体验团队成员的分类操作#

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

更新 labels for issues and PRs ：查看列表 available github labels .
Determine if a PR must be relabeled as stalled 或需要帮助（这在冲刺的情况下通常非常重要，其中的风险是创建许多未完成的PR）
如果停滞的公关被新的公关接管，则将停滞的公关标记为“被取代”，并对停滞的公关链接到新公关留下评论，并可能关闭停滞的公关。
分类问题：
- close usage questions 并礼貌地指示记者使用Stack OverFlow。
- close duplicate issues ，在检查它们确实重复之后。理想情况下，最初的提交者将讨论转移到旧的、重复的问题上
- close issues that cannot be replicated ，留出时间（至少一周）后添加额外信息

Saved replies 有助于赢得时间，但在分类时要保持热情和礼貌。

请参阅github描述 roles in the organization .

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

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

感谢记者开刊

问题跟踪器是许多人第一次与scikit-learn项目本身互动，而不仅仅是使用库。因此，我们希望这是一次热情、愉快的体验。
这是使用问题吗？如果是这样，请发送礼貌的消息关闭它 (here is an example ).
是否提供了必要的信息？

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

我们有很多悬而未决的问题。如果新一期似乎是重复的，请指出原始一期。如果它是明显的重复，或者共识是多余的，请关闭它。确保仍然感谢记者，并鼓励他们参与最初的问题，也许可以尝试修复它。

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

对于错误报告，我们要求报告者提供一个最低限度的可重复示例。看到 this useful post 马修·罗克林（Matthew Rocklin）提供了一个很好的解释。如果该示例不可复制，或者它显然不是最小的，请随时询问记者是否可以提供一个示例或简化所提供的示例。请承认编写最少的可重复示例是一项艰巨的工作。如果记者遇到困难，你可以尝试自己写一份。

如果提供了一个可重现的示例，但您看到了一个简化，请添加更简单的可重现示例。
添加相关标签，例如当问题涉及文档时添加“文档”，如果问题明显是错误，则添加“Bug”，如果是增强请求，则添加“增强”.

如果问题定义明确，并且修复似乎相对简单，则将问题标记为“良好的第一个问题”。

附加的有用步骤可以是标记相应的模块，例如， sklearn.linear_models 相关时。
如果存在“需要分类”标签，请从问题中删除该标签。