GitHub 上的 IPython#
注意
这是从旧的 IPython wiki 直接复制过来的，目前正在开发中。开发指南的这一部分中的许多信息已经过时。
关于使用 GitHub 的注意事项
里程碑#
100% 的已确认问题应有一个里程碑。
一个问题在没有里程碑的情况下绝不应该被关闭。
所有拉取请求都应有里程碑。
所有已关闭的问题应标记为下一个发布里程碑、下一个回退里程碑或 无操作。
未解决的问题应该只有在以下情况下才缺少里程碑：
需要更多澄清 (标签:
needs-info)
通常，会有四个带有开放问题的里程碑：
下一个次要版本。这个里程碑包含的问题应该被移植到下一个次要版本中。有关移植的信息，请参见 下方。
下一个主要版本。这应该是所有问题的默认里程碑。随着发布时间的临近，问题可以明确地提升到下一个发布版本 + 1。
下一个主要版本 + 1。只有我们确信不会包含在下一个版本中的问题才会放在这里。这个里程碑应该在接近发布时大部分是空的。
愿望清单。这是我们目前没有立即解决计划的问题的里程碑。
剩余的里程碑是针对那些不需要采取行动的已打开或已关闭的问题，采取 不采取行动 的策略：
并非实际问题（例如：问题、讨论等）
现有问题的重复
关闭，因为我们不会修复它
当一个问题以 无行动 关闭时，这意味着该问题将不会被修复，或者它根本就不是一个问题。
当关闭一个问题时，它应该总是有一个这样的里程碑之一：
下一个小版本 因为该问题已得到解决
下一次主要发布 因为问题已经得到解决
无操作 因为该问题 不会 被处理，或者它是一个重复/非问题。
一般来说：如果有疑问，标记为 下一个版本。当我们接近某个版本时，我们总是可以推迟。
标签和问题#
问题一旦确认后应始终标记（对于仍在澄清中、可能是重复的或根本不是问题的问题则不需要）。
一些重要的标签：
needs-info: 问题需要提交者提供更多信息，才能继续处理bug: 错误被引发，或出现意外行为enhancement: 非错误的改进backport-X.Y.Z: 此问题的任何修复都应回溯到维护分支。回溯通过里程碑表示，从2.1开始。
prio-foo: 用于排序问题的优先级 - 非必需，但 prio-high/low 对于明确提升/降低问题非常有用，尤其是在接近发布时。ClosedPR: 此问题是对因过时而关闭的PR的提醒。sprint-friendly: 显而易见或容易修复的问题，其中
所有确认的问题至少应有一个 bug 或 enhancement 标签，并且应标记任何受影响的组件（例如 parallel、qtconsole、htmlnotebook），或者如果我们有适当的标签，应标记特定的错误来源（例如 py3k 或 unicode）。
sprint-friendly 标签可能是新贡献者开始的最佳位置。
拉取请求#
所有工作通过拉取请求提交。
一旦有值得讨论的代码，就可以提交拉取请求（Pull Requests）。拉取请求跟踪分支，因此您可以在提交PR后继续工作。审查和讨论可以在工作完成之前就开始，讨论越多越好。最坏的情况是PR被关闭。
停滞的Pull Requests应被关闭（参见[[我们关于关闭PR的政策|Dev: 关闭Pull Requests]]）
拉取请求应始终针对主分支进行（回退PR的描述如下）。
如果可行，拉取请求应进行测试：
bug修复应包括回归测试
新行为至少应进行最小程度的练习
Travis 在测试 IPython 和 Pull Requests 方面做得相当不错，但手动执行测试（可能使用我们的 test_pr 脚本）可能是有意义的，特别是对于影响 IPython.parallel 或 Windows 的 PR。
打开一个问题#
在开启一个新问题时，请采取以下步骤：
在GitHub和/或Google上搜索您的问题，以避免重复报告。针对您的错误消息进行关键词搜索最为有用。
如果可能，请尝试更新到主分支并重现您的问题，因为我们可能已经修复了它。
尝试包含一个最小的可复现测试用例
包含相关系统信息。从以下输出开始：
python -c "import IPython; print(IPython.sys_info())"
并根据问题包含任何相关的包版本，例如 matplotlib、numpy、Qt、Qt 绑定（PyQt/PySide）、tornado、网络浏览器等。
回溯移植#
我们应该为从主分支回溯修复保留一个
A.x维护分支。该分支应称为
A.x，例如2.x，而不是2.1。这样，每个发布系列只有一个维护分支。当一个议题被确定为适合回溯时，它应该被标记为
A.B里程碑。任何解决回溯问题的拉取请求也应获得相同的里程碑。
补丁会被回溯应用到维护分支上，方法是先将拉取请求的补丁应用到维护分支（目前使用 backport_pr 脚本）。