聘请专业项目经理

聘请一名专业的项目经理来处理迁移，类似于 Warehouse 项目的管理方式，将有助于确保此项目的成功。

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

我们应该在 GitHub 上创建一个问题跟踪器游乐场，以便我们可以在其中进行实验和测试新的工作流程。

GitHub 数据备份

这项工作已经开始，并作为核心工作流中的一个问题进行跟踪 [1]。我们每天使用 GitHub 的迁移 API [2] 下载 CPython 的 GitHub 数据。这些存档将存储在 S3 存储桶中。

感谢 Ee Durbin 在这方面的工作。

更新 CLA 主机

目前，CLA 托管在 bpo 内部。它需要更新，以便签署 CLA 不需要 bpo 账户，并且应该托管在 bpo 之外。

当前的 CLA 流程本身并不理想。目前，devguide、peps 和 core-workflow 的贡献者需要签署 CLA，并且需要 bpo 账户。这些项目不应要求 bpo 账户。

目前正在努力开始使用我们自己的 CLA assistant 实例，而不是现有的 CLA 流程。关于此事的讨论已在 core-workflow 邮件列表 以及 Discourse 上开始。

由于 cla-assistant 尚不支持代表组织签署 CLA，这项工作 目前停滞不前。

在 GitHub 上创建“Python 分类”团队

bpo 上的 Bug 分类人员对 Python 核心工作流程非常宝贵，我们肯定需要更多帮助来分类 GitHub 上的问题。

在 Discourse 上已经提议 我们在 GitHub 上创建一个“bug 分类”团队，以协助关闭问题、通知相关方以及为问题和拉取请求应用标签。

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

“Python 分类”团队已创建。分类角色的描述和期望 已添加到开发指南。

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

创建问题分类标签

在 bpo 中，我们目前为每个问题提供以下字段

类型：行为, 崩溃, 编译错误, 资源使用, 安全, 性能, 增强。

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

优先级：发布阻碍者, 延迟阻碍者, 关键, 高, 正常, 低

我们将创建相应的标签

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, ...

此外，我们将创建一个 需要分类 标签。

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

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 可以为问题应用必要的标签。如果问题创建者未提供上述标题，机器人将应用 需要分类 标签。届时，将需要核心开发人员正确标记问题。

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

更新 bedevere

Bedevere-bot 需要更新以识别上述问题标题并应用正确的标签。

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

更新开发指南

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

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

这将需要更新 bpo。但我相信为此所需的努力远小于全面改革。

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

我们需要添加一个新状态：“已移动”，并附上 GitHub issue 的 URL。

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

已迁移的问题

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

将 bpo 设置为只读

这应该是最后一步。一旦我们开始使用 GitHub issues，将 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 上的 @-mention 的形式。

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 指出，可能只有 发布阻碍者 和 延迟阻碍者 有用。