聘请专业的项目经理

像管理 Warehouse 项目一样，聘请专业的项目经理来处理迁移将有助于确保该项目的成功。

在 GitHub 上创建一个 CPython 问题跟踪器

我们应该在 GitHub 上创建一个问题跟踪器，以便我们可以在那里进行试验并测试新的工作流程。

GitHub 数据备份

这项工作已经开始，并在核心工作流程中作为问题跟踪 [1]。我们正在使用 GitHub 的迁移 API [2] 每天下载 CPython 的 GitHub 数据。存档文件将被放入 S3 存储桶中。

感谢 Ee Durbin 为此做出的贡献。

更新 CLA 主机

目前，CLA 托管在 bpo 中。需要进行更新，以便签署 CLA 不再需要 bpo 帐户，并且应该将 CLA 托管在 bpo 之外。

当前的 CLA 流程本身并不理想。目前，开发指南、PEP 和核心工作流程的贡献者需要签署 CLA，并且需要一个 bpo 帐户。bpo 帐户不应为这些项目所必需。

目前正在努力开始使用我们自己的 CLA 助手实例，而不是当前的 CLA 流程。关于此问题的讨论已在 核心工作流程邮件列表 以及 Discourse 上开始。

这项工作 目前已停滞，因为 CLA 助手尚不支持代表组织签署的 CLA。

在 GitHub 上创建“Python 问题处理”团队

bpo 上的错误分类人员对 Python 核心工作流程非常有价值，而且我们肯定需要更多帮助来分类 GitHub 上的问题。

我们已在 Discourse 上 提出建议，以便我们可以在 GitHub 上创建一个“错误分类”团队，以帮助关闭问题，通知相关人员，以及为问题和拉取请求添加标签。

GitHub 上新的分类角色目前处于测试阶段，Python 组织已获得对该角色的访问权限，我们可以开始利用它。

已创建“Python 问题处理”团队。开发指南中已添加了关于分类角色的描述和期望 已添加到开发指南。

该项目的进度可在 “添加分类人员”项目看板 中跟踪。

为问题分类创建标签

在 bpo 中，我们目前对每个问题都有以下字段

类型：behavior、crash、compile error、resource usage、security、performance、enhancement。

组件：2to3、Argument Clinic、asyncio、Build、Cross-build、ctypes、…

优先级：release blocker、deferred blocker、critical、high、normal、low

我们将创建相应的标签

type-behavior, type-crash, type-compile error, type-resource usage, ...

components-2to3, components-argument clinic, components-asyncio, ...

priority-release blocker, priority-deferred blocker, priority-critical, ...

此外，我们将创建一个 needs triage 标签。

最终创建的“标签”可以在稍后开始切换到 GitHub 问题时决定。

Carol Willing 已创建一个包含所有可能标签和颜色方案的测试存储库，可在 https://github.com/willingc/test-581/labels 中查看。

创建问题模板

我们将创建一个问题模板并添加以下标题

---
Type: behavior | crash | compile error | resource usage (choose one)
Components: 2to3 | Argument Clinic | asyncio | Build | ... (can select more than one)
Priority: release blocker | deferred blocker | critical | ...
Needs backport to: 2.7 | 3.6 | 3.7
---

目的是允许问题创建者帮助我们对问题进行分类。以上值已在模板中预先填充。问题创建者将删除不适用于其问题的文本。

基于以上标题，bedevere-bot 可以将必要的标签应用于问题。如果问题创建者没有提供以上标题，则机器人将应用 needs triage 标签。此时，它将需要核心开发人员来正确地标记问题。

我们还可以利用 GitHub 的多个问题模板功能以及通过使用问题模板自动设置问题分配人和标签的功能。

更新 bedevere

bedevere-bot 需要更新以识别上面描述的问题标题并将适当的标签应用于它们。

bedevere-bot 还可以将标签复制到与问题相对应的拉取请求中。

更新开发指南

开发指南应该更新关于使用 GitHub 问题的新工作流程的信息。这可以作为单独的分支进行，并且应该在迁移之前完成，而不是之后。

在 bpo 中添加一个按钮将问题迁移到 GitHub

这将需要更新 bpo。但我相信为此所付出的努力远少于彻底的改造。

我们将创建一个按钮，该按钮位于 bpo 中，它将把问题描述和相关评论复制到 GitHub 问题中。

我们需要添加一个新的状态：“已迁移”，并包含 GitHub 问题的 URL。

我们不应将所有开放问题迁移到 GitHub。只有当有人有兴趣继续工作或讨论该问题时，才应将该问题“迁移”到 GitHub。

已迁移的问题

当问题被标记为“已迁移”时，该问题应该处于只读模式。bpo 应禁止编辑该问题。

使 bpo 成为只读

这应该是最后一步。一旦我们开始使用 GitHub 问题，就使 bpo 成为只读，而不是关闭它。不要接受新注册。不允许创建评论或问题。

bpo 和 GitHub 问题之间的映射

通常，当我们引用 bpo 中的问题时，我们使用 bpo-XYZ，但在 GitHub 中，我们将有一个新的引用，格式为 https://github.com/python/cpython/issue/XYZ。

因为我们将把问题从 bpo 迁移到 GitHub，所以我们需要在 bpo 中添加一个新的字段来引用 GitHub 上的问题，并在 GitHub 中添加一个新的字段来引用“最终”的 bpo 问题。

对于 GitHub，我们需要添加 origin: https://bugs.python.org/issueXYZ。对于 bpo，添加一个新的字段 moved to: https://github.com/python/cpython/issue/XYZ。

通知专家

bpo 中的一个当前功能是自动通知列为某些领域专家的用户。几位 Python 核心开发人员表示他们更愿意不要订阅 GitHub 上的所有内容，而只收到与其感兴趣领域和专业领域相关问题的通知。

为了帮助解决这种情况，我们可以开发一个机器人，它可以在问题被分类使用标签时通知用户。例如，当问题被标记为 area-windows 时，可以通知 Windows 专家。通知可以是电子邮件通知或 GitHub 上的 @ 提及。

GitHub 帐户不应为必需

当讨论将 CPython 代码库从 Mercurial 迁移到 GitHub 时 [3] [4]，有人提出我们仍然需要允许在 bpo 上上传补丁，并且不应要求 GitHub 帐户才能为 Python 做出贡献。

如果 bpo 变为只读，我们将需要提出另一种解决方案，以便允许用户在没有 GitHub 帐户的情况下做出贡献。

一种解决方案是创建一个新的“python-issues”邮件列表，类似于 docs@python.org [5] 邮件列表，以便用户可以在那里提交其问题。

与之相关的是，自 2017 年迁移到 GitHub 以来，我记得有一个案例 [6]，其中一位贡献者向 Mercurial 提交了一个补丁，但拒绝创建 GitHub 帐户。因此，我们的机器人无法检测他们是否签署了 CLA。另一个人自愿将他们的补丁上传到 GitHub。但仍然要求两个人签署 CLA。

这种情况很复杂。它耗费了五位核心开发人员的时间来调查并手动检查 CLA，造成了混乱。

删除“组件”列表

当前的“组件”列表是否仍然有意义且相关？列表可以缩短吗？

优先级列表

当前的“优先级”列表是否有用？Alyssa Coghlan 指出，也许只有 release blocker 和 deferred blocker 有用。